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ABSTRACT 



This thesis describes and tests a system for Low Cost Graphics (LO-CO-GRAF) 
which enables a small computer to generate and display high quality cartographic maps 
from a remote mainframe computer database. A small computer must emulate a 
graphics terminal while interfacing with a mainframe program which processes the nec- 
essary data. This solution has been accomplished through four smaller tasks. 

The tasks include communicating with the source system, emulating a graphics ter- 
minal, interfacing with a map generation program, and producing a local hardcopy of 
the generated map. All software and hardware required for these component parts, in 
addition to the use of standard methodologies, were selected for their widespread avail- 
ability at Department of Defense (DOD) agencies. 

Research was conducted using the Heath/Zenith Z-120 as the small microcomputer 
and the Tektronix 4010 graphics terminal was chosen to model and emulate; two sepa- 
rate source graphics packages were used to generate maps. Concept validation involved 
the use of DISSPLA, the primary graphics package used on an IBM 3033 mainframe 
computer at the Naval Postgraduate School, and the Briefing Aid System, a map gen- 
eration program maintained on the VAX mainframe computer at University of Southern 
California's Information Systems Institute, which was accessed and employed via De- 
fense Data Network (DDN). 

Specific "how-to" instructions were developed for application to the Heath/Zenith 
Z-100 series microcomputer. These instructions, which are provided as Appendices, in- 
clude programs which cause the Z-100 microcomputer to emulate a Tektronix 4010 
graphics terminal, provide microcomputer to mainframe computer communications us- 
ing KERMIT, present interactive DISSPLA map generation programs, and explain how 
to access the Briefing Aid System map generation program via the DDN. 
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A. SOFTWARE 

The reader is cautioned that computer programs developed in this research may not 
have been exercised for all cases of interest. While every effort has been made, within the 
time available, to ensure that the programs are free of computational and logic errors, 
they cannot be considered validated. Any application of these programs without addi- 
tional verification is at the risk of the user. 

B. TRADEMARKS 

The following trademarks are used throughout this thesis: 

• Chromatics is a Trademark of Chromatic Computer Corporation. 

• DISSPLA is a Trademark of Integrated Software Systems Corporation. 

• DISSPOP is a Trademark of Integrated Software Systems Corporation. 

• Epson is a Trademark of the Epson Computer Company. 

• IBM is a Registered Trademark of International Business Machine Corporation. 

• KERMIT is a Registered Trademark of Jim Henson's Muppets. 

• MS-DOS is a Registered Trademark of Micro Soft Corporation. 

• Okidata is a Trademark of the Okidata Corporation. 

• Tektronix is a Registered Trademark of the Tektronics Corporation. 

• VAX is a Trademark of Digital Equipment Cor poration. 

• VM/CMS is a Registered Trademark of International Business Machine Corpo- 
ration. 

• VS Fortran is a Registered Trademark of International Business Machine Corpo- 
ration. 

• Zenith is a Registered Trademark of Zenith Data Systems Corporation. 
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I. INTRODUCTION AND BACKGROUND 



Effective Command and Control (C2) relies heavily on accurate maps and charts 
that are readily obtainable with minimum delay. While pure command post exercises 
of hypothetical scenarios may not be adversely affected by inaccurate, incomplete, or 
artificial cartographic products, any actual movement of men and/or equipment requires 
that the commander and his staff have timely access to comprehensive and up-to-date 
maps. This requirement prevails throughout each step of any exercise, planned maneu- 
ver or crisis management situation [Ref. 1: p. 3-80]. A commander who ignores his map 
requirements during the concept phase of operations is sure to fail. Maps and charts 
are essential tools for those in charge of staffing and planning. General George S. 
Patton, who will always rank as one of the Army's and our nation's greatest warriors, 
stated the importance of maps very simply in his biography. 

A study of the map will indicate where critical situations exist or are apt to develop, 
and so indicate where the commander should be [Ref. 2], 

Perhaps the need for maps is most critical in the execution phase: the success of even the 
simplest operation hinges directly on the reliability and availability of accurate maps and 
charts. To put it simply, timely access to maps and charts is an indispensable C2 tool 
and must be available at all levels of command during all phases of the C2 process [Ref. 
1: p. 3-82]. 

The usual procedure for obtaining maps in the Department of Defense (DOD) is to 
request them from the Defense Mapping Agency (DMA) or one of the affiliated military 
distributing commands. This requires intricate preplanning for anticipated future needs, 
as well as a long lead time of anywhere from a few weeks to several months due to the 
logistics involved in physically locating, obtaining, and delivering the desired maps and 
charts. To expedite this process, the DMA has digitized most critical world areas so that 
the cartographic information can be transmitted electronically. This innovation, while 
an important first step in providing accurate and timely map data, is somewhat limited 
in its present configuration because only specially dedicated computers and network 
systems can access the information. However, this information is available on many 
mainframe computers and accessible through resident graphics packages. l Indeed, many 

1 For example, the Naval Postgraduate School (NPS) uses the Display Integrated Software 
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of the large screen displays currently used in C2 centers for contingency planning and 
for the World Wide Military Command ard Control System (WWMCCS) displays are 
of inferior cartographic resolution. Most importantly, the DISSPLA software allows 
anyone operating a NPS graphics workstation to generate the exact cartographic 
projection desired. The significance of generating detailed cartographic products by 
DISSPLA, is that most organizations also have a similar, unrealized capability to have 
this type of small scale, large area mapping program, which can provide them almost 
instantly with the maps and charts they require. 

A. GRAPHICS IN THE MILITARY ENVIRONMENT 

This thesis is specifically directed towards the creation of maps and charts, which 
usually represent the highest level of capability available in graphics packages. The dif- 
ficulty to genera": - aps involves translating a three-dimensional data set generated by 
the curvature of the earth into two-dimensional projections that can be printed as maps. 
The need for accurate maps and charts has already been mentioned in general but the 
following specific applications serve to better illustrate this requirement. 

1. Command and Control (C2) 
a. Pre-planned 

Maps are always needed when forces are being employed or deployed. C2 
is exercised^ via Command, Control, and Communications (C3) systems; the commander 
and his subordinates must be "working from the same sheet of music". The exchange 
of information necessary to achieve a successful mission is critical, and usually very 
susceptible to error. To relay his C2 decisions, the commander could prepare an inter- 
active computer menu program3 which could be made available to other commands, 
making clear the decision. The maps with overlayed or imbedded information could be 
either electronically transmitted or simply made accessible to others. This delicate C3 
problem is resolved with a C4 (add "Computers" to C3) solution. Figure 1 illustrates the 
dissemination of a map presentation from the commander and his staff to other elements 

System and Plotting Language (DISSPLA) graphics software program which contains a map gen- 
eration option called World Coast Utilities. Although this program is independent of the DMA 
database, and therefore does not reflect the continuous DMA updating of maps and charts, it can 
generate high resolution products that are amply sufficient for the strategic and operational/theater 
levels of military planning and execution. 

2 C3 is sometimes referred to as "the reins of command", that is the commander's ability to 
maintain control of the situation. 

3 Similar in concept to the program provided in Appendix A in that different options or bases 
for decision can be provided electronically. 



2 




Figure 1. Use of Digitized Maps in Normal Operations: Distribution of 

commander's intentions, EOOB, admin/log information, and C3 proc- 
esses of the C2 functions through Local Area Networks (LAN), Defense 
Data Network (DDN), or telephone quality communications lines. 



in his chain of command. With this map distribution tool, the commander can provide 
timely progress reports to his superiors, advise and inform adjacent commanders of his 
intentions, and effect swift, unambiguous C2 direction to subordinate command ech- 
elons. 

b. Emergency I contingency! crisis situations 

Similar to the preplanned, deliberate scenarios, a commander's effectiveness 
in a crisis situation can also benefit from a C4 application of digitized mapping. Speed 
and accuracy of information transmission is Dossiblv even more critical during an emer- 

* A m W 
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gency or crisis because decisions are being made and forces deployed with all possible 
speed. A precise display of forces and enemy order of battle from his superior's com- 
puter could prove invaluable -to the on-scene commander. Additionally, weather and 
other displays could be made instantly available to him. 

Most contingency operations usually are directed from a major command 
center. The personnel handling these emergencies are usually referred to as a Crisis 
Action Team (CAT) or a Crisis Management Team (CMT). Their composition is made 
up of operators and specialists in communications, logistics, intelligence, and other 
warfare and combat support occupations. Figure 2 demonstrates how the on-scene 
commander and the CAT or CMT can access tactical maps requiring only communi- 
cations to some remote mainframe computer. Figure 2 also demonstrates another ad- 
vantage of digitized maps: the graphic link between the on-scene commander and the 
Crisis Management Team which reciprocally would provide up to the minute decisions, 
results, and options. 

2. War gaming 

a. Laboratory 

C3 is usually ignored and not normally a determinant in laboratory 
wargaming exercises. However, the highly specialized systems employed to generate 
terrain and similai cartographic displays are available only at major commands and in- 
stallations, limiting their usefulness to a small, elite minority. Using digitized maps, 
many wargaming systems could become available at lower level commands. With the 
loss of dependence on highly specialized displays and systems, more inter-command or 
distributed wargaming could occur. This would result in more training for more forces, 
with obvious benefits accruing therefrom. 

b. Exercises 

Using wargaming in conjunction with field exercises is extremely beneficial. 
Instead of being limited by time and cost constraints, different options or hard to field 
operations can be conducted. The availability of digitized mapping programs and the 
increasing presence of highly accurate and current DMA data, would allow more play- 
ers, more and easier access, and potentially higher quality wargames and exercises. 
Again, the benefits are readily apparent. 

3. Other 

This thesis is primarily directed towards cartographic products, but it is equally 
applicable towards other graphics products. Strategic analysts, as well as tactical 
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Figure 2. Use of Digitized Maps in Crisis Situations: Instant accessibility is re- 

quired by the on-scene commander and the crisis management/action 
team. 



commanders, monitor the activity levels of numerous indicators [Ref. 3: p. 86] such as 
enemy order of battle, troop strength, logistic support, levels of supplies, casualty rate, 
weather, etcetera. These indicators are often not quantifiable and depend on some other 
previous analysis. When only men were in this loop, knowledge of the general situation 
and of the other analyst's psyche w r as sufficient to judge the quality of a decision. The 
current trend in technology and sensors is to place a greater reliance on the use of Arti- 
ficial Intelligence (AI), specifically Expert Systems. Versions of these AI systems process 
raw sensor data, perform primary estimations, and then effect dissemination [Ref. 3: p. 
35]. This is the best solution when dealing w'ith: 
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1. High threat or short reaction time weapons response. 

2. Sensor systems which deliver massive amounts of raw data from which usable in- 
formation must be derived through algorithmic processes. 

3. Repetitive, and very subtle, information sources where changes in state may not 
be detected by casual or distractable observation. Also as a guard against mislead- 
ing information or disinformation where the target observation system has known 
limitations. 

The application of Expert Systems in C3 is ongoing; however, the analyst and 
commander no longer know the man who is feeding them the information on which they 
are basing decisions (and possibly lives). These AI/Expert Systems are generally decision 
tree or probabilistic based. For a human to enter into this system in the middle of the 
cycle, a graphical representation of the AI system's knowledge could be available. In 
Decision Support Systems (DSS), a common presentation vehicle is the Probable Fu- 
tures Map [Ref. 3: p. 121]. With this information, a commander could better understand 
the conclusions and recommended options from his intelligence and decision support 
systems. These graphic representations are easily transmitted; a graphics capable 
microcomputer is needed to display them. This thesis turns one of DOD's most com- 
mon microcomputers, the Zenith Z-100 series, into an available graphics terminal. 

B. WHY THIS PROJECT IS IMPORTANT 

This C2 problem needs to be addressed with a C4 solution. In a time when rapid 
transfer of data is common-place, a commander should no longer have to depend on a 
hard copy of a map or chart being carried to his subordinates and superiors. Neither 
should the tactical commander be tied excessively to his chart bag or map case. 

1. Current svstem 
a. Requests 

The current system requires that requests for cartographic products be 
submitted to DMA or one of its military distribution centers for issue. The tactical 
commander usually needs one or two copies of each map in each of the areas he is ex- 
pected to operate. This relies heavily on forethought to ensure all necessary maps are 
ordered and kept on hand. The burden is also on DMA to generate, print, store, and 
then distribute maps to users. Allowing users to access digitized mapping files, develop 
their own projections (usually of a tactical scale), and electronically receive the product 
would significantly reduce man-hours, printing costs, and warehousing requirements. 
DMA would need to develop some user friendly programs in order to allow access and 
to maintain high standards for their cartographic products, but this could be easily ac- 
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complished within the scope of current assets. The recurring theme of the problem this 
thesis addresses is that maps and charts can and should be received in a more timely 
manner. 



b. Contingency 

The commander and his stafF routinely have literally hundreds of charts and 
maps which are carried around for contingency purposes. These maps of these require 
continuous updating and are regularly superceded and replaced. The requirement to 
maintain large quantities of maps adds associated logistic and manpower burdens. 
There is a need for an alternate means of obtaining up to date maps and charts in the 
fulfillment of a contingency requirement.** 

2. Suggested Approach 

Commanders should be able to transmit their situation and intentions on maps 
both up and down the chain of command. This thesis investigates that objective using 
no cost or government proprietary software and a microcomputer (the Heath/Zenith 
100) that is widely available and well-suited to the job. The ability to pass maps and 
charts electronically has several significant benefits to the users, the mapping agencies, 
and DOD as a whole. Some of these possible benefits are listed below: 

1. Immediate availability of high quality, updated maps and charts to lower echelon 
commanders. Though not being able to replace typeset printed maps, an elec- 
tronically transmitted version with the necessary information overlayed or imbed- 
ded would be an improvement over lesser quality products. 

2. Independence from some of the logistics tail of most commands and all staffs, that 
is chart bags, map cases, and their associated files. Maps and charts for locations 
not in a commands area of responsibility (AOR) could be called electronically, 
rather than keeping a hard copy on-hand. 

3. Decreased requirement for DMA printed maps and more time available to order 
correct maps and charts before the detailed planning and execution phases. 

4. Decrease in manpower requirements to keep chart and map allowances updated. 
The emphasis on maps and charts for a command's AOR being always up to date 
and other areas being available on-call electronically. 

5. Better utilization of common, general purpose military microcomputers for more 
missions. 



4 The needs of a tactical commander cannot be fulfilled by this type of system at this time. 
The transfer of tactical quality maps electronically is currently an option using specialized graphics 
terminals only, however this capability has been extended to some major Air Force C2 commands 
as of this writing (see Chapter I.B.3.a below). 
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a. Electronic distribution 



DOD agencies have started using the Defense Mapping Agencies (DMA) 
database of digitized maps. This is usually accomplished with a dedicated mainframe and 
a graphics workstation. Accessing the DMA World Data Bank II, one can build maps 
of any location in the world. To build the map, enter the center of the desired map and 
then the directional distances from the center to be displayed. The system automatically 
retrieves, draws, and then scales the map. Features include coastlines, waterways, poli- 
tical boundaries, roads and railroads; additionally, latitude and longitude, UTM, or 
GEOREF grid systems can be overlaved[Ref. 4: p. 44]. 

b. Generation 

In addition to accessing DMA maps, mainframe computers can also be used 
to m? ;, *.tain their owm databases of graphics software. Cartographic products generated 
by these programs could be sent and received throughout the chain of command. The 
ability to send and receive graphics products up and down the chain of command would 
result in consistent quality of information and less confusion due to interpretation of the 
written word5 . A side benefit could also be realized with the distribution of other 
graphics products for visual affect and emphasis. 

c. Existing systems 

There currently exist several digitized mapping programs for microcomput- 
ers. Many are available through user's groups and via computer bulletin boards, but 
all of them have limitations which will not fulfill the requirements of this thesis. A brief 
review of some of these products follows. 

(1) Map Maker. The program Map Maker produces two forms of 
quantitative maps: choropleth (area coloring) and graduated circles. Any set of statis- 
tical values may be displayed for its corresponding geographic area. Map areas are 
limited to states, counties, census tracts, or areas defined by the user.[Ref. 5: p. 67] This 
program is typical of those developed for the social sciences and demographics. Its re- 
solution and accuracy would probably be inadequate for military purposes. 

(2) World Map. This software allows users to generate a world map on 
the screen and even to zoom into various areas. Only boundary lines are drawn on the 
map and there are no details. The map is very good for allowing the user to set a latitude 
and longitude and then zoom in on the area in question. A number of cities and capitals 
are given and can be located and zoomed in on from the world map. [Ref. 5: p. 83] This 

5 A picture is worth a thousand words. 
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program could be useful to the strategic level planner who is only concerned with low 
cartographic resolution maps. Lack, of data points would seriously hinder lower level 
planners who require greater accuracy and detail. 

(3) World Digitizer. Another new map generation program is World 
Digitizer which has a similar capability to World Map, described above. It is written in 
the language C and performs all of its functions very quickly. The data it uses to gen- 
erate maps is composed of one million connected latitude and longitude points. This is 
the first program reviewed which specifically warns the user of its inaccuracies. Its ap- 
plication to strategic and operational planners uses is possible. 

(4) Micro D EM, formerly Terrain Analysis. This program provides dig- 
ital topographical support. The program uses Digital Terrain Elevation Data (DTED) 
Level I produced by DMA, but the characteristics of the data limit its capability and 
require careful analysis of its results. The program can dump to a printer line of sight 
profiles, weapons or sensor masking plots, color tinted elevation maps, slope maps, and 
three dimensional oblique views. Data sets used by the computer cover 15 minutes of 
longitude, which corresponds to a standard tactical map. Programs are available for the 
Fulda Gap (16 disks), the Korean DMZ (5 disks), and Fort Irwin/ West Point (1 1 disks). 
[Ref. 5: p. 18] This program is highly accurate and is updated regularly. However, the 
logistics trail to provide replacement and corrected disks would represent no major im- 
provement over the existing system with regards to logistics, manpower burden, nor 
timeliness. Exploration of this system resulted in this thesis advocating the use of 
mainframe computers to generate the maps required, whether organically produced or 
drawn from DMA data. Regardless of the microcomputer advocates' claims that their 
machines can do it all, some jobs remain too large. The microcomputer is better used to 
display a map the mainframe has stored for it, and then to print it. 

3. Direction of Computer Mapping 

There exist two distinct categories in which the military commander or his staff 
would need to generate maps. The first is the strategic and operational^ levels of com- 
mand. The requirement would be for large area, small scale maps on which a commander 
could place symbology, icons, or text for broad direction and situational reporting. 
Accuracy and resolution quality would be secondary to convenience and speed of use. 
Ideally, situation reports and concept of operation maps could be prepared-, easily stored 

6 Operational level of command can be roughly equated to the theater level or the area in 
which a corps commander would operate. 
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and instantly accessible to subordinates and superiors. The maps could readily be played 
back by remote units requiring only a small graphics capable computer and a modem 
(Ref. 6). The second situation occurs when lower level users employ maps and charts 
for tactical purposes. The programs mentioned in the previous section either lack suffi- 
cient resolution or require dozens of computer data disks to present a specific area. The 
resolution problem is unacceptable, when resolution needs to be 10 meters or less. The 
multiple disk problem offers no logistical or timeliness improvement over the current 
system of carrying bundles of charts or maps. This situation would require that the 
maps be created from a highly accurate and continuously updated cartographic data- 
base. Access to DMA online digitized maps would be a necessity. Some attempts at 
integrating the DMA data bases into a real-time enviroment are being attempted. A 
sampling of these programs follow. 

a. TRACE 

The U.S. Air Force is currently purchasing an automated decision support 
tool for C3I called Tactical Resource Allocation for Combat Effectiveness (TRACE). 
This system is available from Lockheed Missiles and Space Company or through Chro- 
matics, Inc. The object is to develop a flexible and transportable system which can allow 
a command center to reduce time in resource planning and allocation. TRACE runs on 
a Digital Electronics Corporation (DEC) VAX computer with the Chromatics CX1536 
High Resolution Graphics display. The programming is in Fortran and Graphical Kernel 
System (GKS). This combination of hardware and software allows real-time generation 
of maps using DMA digitized data.[Ref. 4: p. 44, 46] Though this system works at the 
command level, it is too hardware dependent ever to become available ?X the tactical 
level. Soon, this system will allow the strategic and operational planners to generate 
high quality maps and, hopefully, to disseminate them to lower echelon commanders. 

b. National Marine Fisheries Services 

The National Marine Fisheries Services (NMFS), which operates under the 
National Oceanagraphic and Atmospheric Agency (NOAA), has been developing the 
capability of a small graphics capable computer to display DMA or NOAA maps and 
charts. The computer emulates a Tektronix 4010 Graphics Display (similar to the em- 
ulator used in this thesis) and the reports indicate that the concept is feasible. Opera- 
tional evaluation was conducted at Galveston, Texas. [Ref. 7] 
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c. Future DMA products 

DMA is in the process of developing a film digitization capability which 
would be used in the future for a digital point positioning data base product. (Ref. 8] 
Access to this type of information would be available via the same means as 
cartographic data and could be similarly displayed. This is another tactical tool which 
can be utilized and should be explored in the future. 
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II. METHODOLOGY 



A. APPROACH 

This thesis will identify all components of a Low Cost Graphics (LO-CO-GRAF) 
system to address the problem of generating maps, transferring the maps between users, 
and producing a hard copy of that map from a command, control, communication 
and computer (C4) perspective. Computing and communicating between computers 
and data networks will be the central focus of the approach, with an additional re- 
striction that this be a no/low cost solution to the problem. With the appropriate 
set of equipment and softw^ -e attributes, commanders can enlist the aide of com- 
puters to ease some of the burdens of command and control. The combined use of 
mainframe computing power and the ability to communicate or translate that power 
to smaller more accessible computers will provide a valuable tool to the commander and 
the command and control function. The set of remote "source" systems that generate 
the graphics, local microcomputers, communications software, the graphics terminal 
emulator software program and the software required to print out graphics products 
will comprise the LO-CO-GRAF system. As seen in Figure 3, which provides an over- 
view of the system architecture and components, communications software will enable 
each remote terminal to transfer data from the mainframe computer (or other graphics 
source system) to other user terminals. The programs required to send the electronic 
maps are available for most microcomputers and are an essential component of the 
system. The program required to playback or display the maps can be transferred within 
the system's terminals, as well as the printing programs. 

1. Advantages 

The LO-CO-GRAF system will take advantage of the high quality graphics 
programs and large storage potential characteristically available on mainframe com- 
puters, while using them to perform the calculating and plotting functions required to 
produce maps and other high quality graphics. Taking this approach will overcome 
some of the problems encountered by other map generation programs which tried to 
perform all of the functions on the microcomputer. Utilizing a mainframe also takes 
advantage of the fact that the database is constantly being updated by the Defense 



12 



L©=C©=GimlF 



/ / 



v 

A 

w 










1 / 






0 


bO 


/ 



Syiiii 




7 



r 



J 



V) 



Remote Graphics 
"Sou res” 




t 



Dot Matrix U Printer 



Communications'^ Software 






<3= 



Emulation and 



Other Remote Z L Network Members 




Printer Software 



Figure 3. The LO-CO-GRAF System architecture. 



Mapping Agency, providing up-to-date information.? The C2 community must be able 
to access this information from remotely located terminals in order to obtain the greatest 
benefits. With the aid of a communications software package and terminal emulator 
this can be accomplished at little or no cost by utilizing equipment assets already 
available to most organizations. 

2. Distributed 

Doing the work remotely is a major point where LO-CO-GRAF departs 



7 Being able to access and process the DMA databases, that is the digitized cartographic pro- 
ducts, as they become available circumvents the delay associated with the logistics lag time involved 
with ordering maps. 
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from similar graphics programs.8 By accessing a remote source which will actually 
generate tne derived graphics and by keeping that function separate, the microcomputer 
is free from the major task of maintaining the sizable database required to generate 
the maps and avoids the problem of trying to manipulate and process all that data. 
After downloading the high quality graphics products from mainframe computers and 
other sources, it can be translated to a form that can be understood, displayed, stored, 
redisplayed, and transmitted to other users. There are commercial and military hard- 
ware and software packages available that provide the capability to process DMA 
data or generate maps and other higher level graphics. Unfortunately these 
systems are very costly and require too much memory storage capability or too 
many hardware enhancements to be widely employed without incurring large costs to 
implement. The objective of this thesis is to demonstrate that a system could be made 
widely available at no cost to the users, by taking advantage of existing assets. 

To accomplish this goal, it is necessary to make a few starting assumptions. 
First, what is the working environment? And then, what equipment can be expected 
to be available in the C2 community? 

B. ASSUMPTIONS 

The first assumption is that the LO-CO-GRAF system should be capable of 
transmission over telephone networks. This type of operation will allow the head- 
quarters or the central C2 controlling node to bring in other new members and share 
the graphics among a set of operational units or commands. The only requirement is 
that that unit have a similar set of hardware and software available. 

Some hardware is universally available to support the C2 components wishing to 
use, produce and transmit graphics products. The software required will be intro- 
duced or provided as a by-product of this thesis. The real contribution of the 
LO-CO-GRAF system is the ability not only to obtain the graphics, but also to 
transmit any maps generated along with the software necessary to use it. Some as- 
sumptions follow about the working environment and the assets available. 

8 Microdem and Terranal, for example, use data which has been processed and prepared 
to enable a small computer to then generate maps locally. One problem with this process is that 
you need to keep all the data on hand locally and then reprocess it as needed. The data disks 
required are very cumbersome and are just as difficult to keep current logistically as paper maps. 
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1. Sources 

High quality graphics products are available on many mainframe computers 
which are capable of processing raw data and generating maps. Most, if not all, 
mainframe computers have resident programs to perform high quality graphics func- 
tions. The graphics programs are either capable of generating their own maps, as in the 
case of Display Integrated Software System and Plotting Language (DISSPLA) pro- 
gram, or are capable of processing DMA data to plot maps from raw data. 

In the case of a remotely located C2 terminal, the mainframe will not be acces- 
sible by a direct connection to the microcomputer. Connecting will require access 
through some communications system in order to make the graphics program available. 
"Available" means obtaining access to the mainframe through a modem and communi- 
cations software package or communicating to some other graphics generating facility, 
such as those available on the Defense Digital Network (DDN). In either case, the 
operative word is available. An additional requirement for this thesis is to implement 
LO-CO-GRAF at no additional cost. Next, the problem of establishing communi- 
cations between the remote mainframe (or other map source) and the local 
microcomputer must be addressed and resolved. 

2. Communications 

Communications software is readily available at no cost as freeware or Gov- 
ernment proprietary software and in most cases is already available on a mainframe 
computer available to the potential users. If no communication software package is 
available, one must be obtained, again at no cost, in order to stay within the low cost 
(no cost) objective. This thesis assumes there is a communications software package 
available which will enable communications between the remote map generating system 
and the local microcomputer. 

For the case where no communications system is available to provide access 
to the mainframe, instructions for obtaining the software will be provided within this 
thesis. The software must be adaptable to as many different mainframe computers as 
possible to allow access to all the many types of graphics source machines available. 
The communications software must also provide for communications between the 
graphics sources and to the microcomputer. 

3. Microcomputer 

The microcomputer must be capable of translating and processing the 
graphics data. The Zenith Data System Z-100 microcomputer is both capable and 
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available. There are many Z-100 computers in the military inventory which are not 
utilized to their full capability.9 The Z-100 was chosen because it has very good built-in 
graphics capabilities, which will be discussed later in greater detail in Chapter III. 

To take full advantage of the resident graphics capability of the Z-100, a 
software program will be developed and documented as part of this thesis to make it 
emulate a standard high quality graphics terminal. Through emulation, the Z-100 will 
gain the ability to process, display, and store (map) graphics. After storing the data, 
the last step is to be able to recall or redraw those saved images as well as print them 
out on paper. 

4. Printers 

The last assumption is that there will be a requirement to print any maps or 
other images which are generated by LO-CO-GRAF.10 Choosing a graphics screen 
dump program which applies to several of the more common military printers will pro- 
vide a way to print any map images saved by the terminal emulator program. 



9 The major reason for not fully utilizing the Z-100 capabilities is that they are neither soft- 
ware nor hardware compatible with the more recent and popular International Business Machine 
(IBM) personal computer (PC) machines. The differences are examined in detail in Chapter III.C. 

10 There are many dot matrix printers throughout the DOD in both militarized and com- 
mercial versions. The Epson MX, Okidata Microline, and Zenith MPI-99/150 series dot matrix 
printers are examples of standard DOD printers. 
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III. TECHNICAL EXPLANATION 



A. MAP GENERATION 

The ability to generate maps for strategic or theater level operations is commonly 
available in mainframe graphics programs. The mapping characteristics may include a 
variety of coastlines, political boundaries, and waterways, as well as selection between 
the different types of projections. The major limitation is that only a limited number of 
data points have been saved for the maps to be drawn from. Two unique resolution 
problems are encountered while creating maps. First, the aforementioned lack of data 
points can only generate maps with resolution measured in kilometers (possibly fractions 
of kilometers). An example of this type of resolution problem can be seen in Figure 4. 
Secondly, display resolution is limited by the type of computer monitor being used and 
also by printer resolution characteristics. 

1. Resolution Problems 

The standard definition of resolution is the smallest distance between two dif- 
ferent points that is distinguishable. In printer terms, the expression used is "dots per 
inch" or dpi (a typical laser printer can perform 300 dpi or resolution to 1/300 of an 
inch). For computer monitors, resolution is stated in the number of pixels, that is, the 
number of points on a screen displayed vertically and horizontally. The number of dots 
per inch is not fixed by the computer screen, though. Just as a television picture looks 
less grainy on a small screen, a computer monitor with a 13-inch screen will look better 
than a 19-inch screen. This is because the picture is really made up of a fixed number 
of pixels, the larger the screen then the further apart the dots will be [Ref. 9: p. 34]. 
Resolution can be changed by the user in both the horizontal and vertical by adding 
hardware upgrades to the graphics circuitry, therefore manufacturers refer to the total 
number of pixels displayed. A common example would be the Color Graphics Adapter 
(CGA), which has a color resolution of 320 by 200. 

Table 1 presents a sampling of devices, their actual resolution, and their pres- 
entation characteristics. These numbers must naturally be compared to the visual acuity 
of the human eye. Typically, a person can distinguish objects one degree apart at six 
feet. Human vision remains highly dependent on distance, contrast, color and shading, 
shapes, brightness and darkness, and the viewer s age (Ref. 10). 



17 




Figure 4. Example of resolution problems: Map of Washington, DC area. 

Returning to the television example, a typical television monitor only produces 
200 lines of resolution, much less than that possible with a graphics adapter. Yet to the 
eye it is more than sufficient to portray an image. The reason for this is the large number 
of colors or shadings being used. This multi-color, low resolution technique is excellent 
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Table 1. SAMPLE RESOLUTIONS 



Screen Resolution 


Actual Resolution 


Lines/char 

@ 12 pt 


320 X 200 on 13" 


36 ppi (horizontal) 
30 ppi (vertical) 


5 


640 X 480 on 13" (Z120) 


72 ppi 


12 


1024 X 768 on 16" 


90 ppi 


15 


1536 X 1152 Chromatic 
CX1536 (TRACE) 




24 


Dot matrix printer 
(standard 9-pin) 


up to 240 dpi 


40 


24 -pin dot matrix printer 


up to 360 dpi 


60 


Laser printer 


300 dpi (typical) 


50 


Typesetter 


1200 dpi 


200 



Taken in part from [Ref. 9: p. 36] and manufacturer's specifications. 



when displaying real-life images, but inadequate for text images [Ref. 9 : p. 35]. The 
problem is heightened by the intense resolution/accuracy requirements needed for 
mapmaking. The anti-aliasing schemes used to improve the appearance of text on a 
monitor would only introduce error into cartographic representations. 

2. DISSPLA 

The graphics package available on the IBM 3033 mainframe computer at NTS 
is the DISSPLA program. This system was developed by Integrated Software Systems 
Corporation (ISSCO) of San Diego and is widely used throughout the Navy, DOD, in- 
dustry, and other academic institutions [Ref. 11]. According to DISSPLA, any desired 
graphics product can be achieved within one to two hours, using the interactive system. 
Some of the products include specialized business, cartographic projections (of interest 
to this thesis), and a dynamics program. All of which are detailed for practical applica- 
tions in the DISSPLA User Guide [Ref. 12]. 

Automated graphics is a powerful and useful computer application of 
significant importance to distributive computing and wargaming in the military. The 
capability to plot computer generated maps on demand is an essential tool for opera- 
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tional commanders, as well. There are many software packages which provide programs 
of commands and subroutines to produce very powerful graphics outputs. The 
geographic data required to plot the maps is stored in mass storage in several 
resolutions[Ref. 12: Part D], which can be called to generate maps of various 
projections. 

a. Programming 

DISSPLA was developed using Fortran IV constructs. Current Fortran 
compilers use Fortran 77 or, if an IBM system, VS Fortran. Both are fully backwards 
compatible and have the greater variety of options for entering data which aids in 
cartographic design and engineering. 

The DISSPLA package is actually a library of FORTRAN subrou- 
tines which can be called and arranged with other FORTRAN source code to gen- 
erate the desired map. It required a great deal of time to learn how to organize these 
subroutines to generate maps and plotting a few maps of different theaters of opera- 
tion to show the power of this DISSPLA option. 

The process of calling subroutines at various levels within the DISSPLA 
package is perhaps the most difficult concept, but not the first that can cause trouble. 
To use DISSPLA means one will interface through a set of more than 300 user- call- 
able subroutines. The subroutines access a network of usually invisible (except 
when an error condition occurs), internal sub-subroutines which communicate with 
each other using blocks of more than 200 variables. As can be seen, calling a subrou- 
tine is no simple matter. The logic flow in DISSPLA is unidirectional through more 
than twenty levels of subroutines. 

By levels, it is meant that a call on one subroutine may do nothing more 
than set a parameter or flag a variable for use by another subroutine, or a subroutine 
occurring later on in the program. Calling a subroutine that depends on another 
subroutine which has not already been called will cause you to go into computer 
"Never-Never" land. Fortunately, to generate maps one will only have to specifically 
address four kinds of routines to change to proper levels. 

The program listings in Appendixes A and B, emphasize comments which 
show the transitions between programming levels. Using the programs listed in Ap- 
pendix A, one will not need to know a great deal about the levels to generate maps, 
but should understand that they exist and can cause great difficulty when generating 
complicated plots if they are not accessed in the correct order.[Ref. 11] 
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b. Running DISSPLA 

To use DISSPLA under VM/CMS, one must link to the support disks 
which contain the data files. This involves establishing appropriate input and 
output files, file definition statements, and text library programs, which is a tedious and 
time consuming process. There is an execll , DISSPLA EXEC, that must be used to 
actually run a program and link to all the appropriate files and create the correct envi- 
ronment to work in DISSPLA. 

An on-line help file is available by typing "disspla ?". Although this file is 
helpful, it does not make it easier to create three dimensional plots (maps are two 
dimensional projections of three dimensional data points) nor does it address how to 
generate a map specifically. The most valuable source of information for plotting maps 
is contained in the DISSPLA Pocket Guide [Ref. 12: Part D]. It contains several ex- 
ample programs with more information about the calling of map plotting subroutines. 

c. DISSPOP option 

When the DISSPOP option of DISSPLA is called, the output is a device 
independent plot file, rather than an actual plot. This file is called a metafile and is highly 
compressed. It can be interpreted by one of a selection of post-processor programs for 
output to a particular device. [Ref. 12: p. F-l] Exercising the DISSPOP option, or a 
similar capability under a different graphics program, a commander could generate the 
map or chart with any necessary information attached and then store it. Any subordi- 
nate or superior with a graphics device listed in the DISSPOP post-processor device 
menu could then instantly retrieve, display, and print (if they also have that capability) 
these maps and charts. The use of a device independent plot file will have to be a ca- 
pability included in a command center's map generation program. 

B. COMMUNICATION 

The second part of the solution involves establishing a way to communicate be- 
tween the mainframe and a remote microcomputer. Computer to computer communi- 
cations requires a working knowledge of the technical characteristics of both machines, 
a modem, and a basic understanding of communications software. First, a discussion 
of the functions of the modem and how it provides the connection between the remote 
graphics generating system and the microcomputer. 

1 1 An exec is an executable file, which when called will initiate programs and configure your 
operating system or virtual machine for a specific task. 
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1. Modems 

There are two basic modem configurations, internal and external. Elec- 
trically there is no difference and the procedures that follow, as well as the software to 
be provided/introduced, will work with either variety. All modems are rated in terms 
of their transmission speed. The ratings are in baudi2 (e.g. 300, 1200, 2400, ..etc.), 
which refers to the number of bits per second the modem is capable of transmitting or 
receiving. A 1200 baud modem will transmit and receive data four times faster than 
a 300 baud modem, and half as fast as one rated at 2400 baud. Most communications 
software systems today allow connection at any speed, but the faster the better. 

2. Communication Software 

A communications software program is used to access a communications 
ne.'rcrk or remote system. This allows the microcomputer to dial the necessary 
telephone numbers, establish an electrical connection, and then communicate with the 
remote system. The remote system may be a mainframe computer, another 
microcomputer or a data communications network, like the Defense Data Network 
(DDN). The main function of this software is to make the remote system recognize your 
microcomputer as an input/output terminal. 

By electrically looking like an input/output terminal, the microcomputer can 
talk to the remote system over telephone lines as if it were connected (hardwired) to the 
other computer system directly. Most communications software programs will also 
allow transfer of files and programs from the microcomputer to the remote system and 
vice versa. The file transfer feature will play an important part in the LO-CO-GRAF 
network so it is important to select a program which utilizes a standard communications 
protocol. The communications software package selected for this thesis has been de- 
veloped for over 200 different computers and microcomputers. 

3. KERMIT 

KERMIT actually stands for K110 Error-free Reciprocal Microcomputer 
Interconnection over Teletype (TTY) lines. This computer communications protocol 
designation was established when CP/M was the preferred microcomputer operating 
system and it was not changed as the system was later developed for use with other disk 
operating systems (DOS). 

12 Baud rate is a measurement of the capacity of a communications channel to pass informa- 
tion. 
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KERMIT was developed and written at the Columbia University Center for 
Computing Activities as a packet switched file transfer and communications pro- 
gram. KERMIT is not necessarily better than other programs but it is free and it 
has been adapted for use on many micro, mini, and mainframe computers. The partial 
list in Figure 5 shows a few of the more popular versions. 

Every version that has been implemented is available from the Columbia 
University KERMIT Distribution Center.13 The program can be downloaded by any 
file transfer system with a modem connection or by accessing the distribution center 
through an electronic data system like the Defense Data Network (DDN). A com- 
plete set of instructions are available (Appendix D) which provide all the instructions 
necessary to access the KERMIT archives. Once you have obtained a copy of 
KERMIT it must be set-up with the correct parameters to use it in the LO-CO-GRA p K 
system. 14 

4. Utilization 

There is a very exhaustive manual available in disk format which explains all 
the parameters and options for using KERMIT. It is beyond the scope of this thesis 
to explore all the abilities of the program itself. An instruction guide which explains 
all the steps necessary to operate KERMIT, as required for the LO-CO-GRAPH sys- 
tem, appears as Appendix E. 

The KERMIT instruction guide is written specifically to allow connection of the 
Zenith Z-100 to the International Business Machines (IBM) 370 mainframe. It is 
not necessary to know anything more about KERMIT to use it as the communi- 
cations software in this system. Minor modifications to the set-up procedure will al- 
low connection to the Defense Data Network. 

Connection to the DDN and or mainframe will allow access to a graphics 
program designed to generate high quality graphics and maps. These programs 
require a graphics terminal or workstation quality monitor in order to display the 
graphics. This leads into the next area of the project. It is necessary now to make the 
remote graphics source system think the microcomputer is a graphics processing termi- 
nal. 



13 The center maintains a file (Appendix C) on their computer which contains a much 
more comprehensive list of KERMIT applications and provides all the information needed to 
fmd the correct version for your computer. 

14 This will be discussed at length in Chapter IV. 
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MACHINESf S") 


OPERATING SYSTEM 


LANGUAGE 


Micros and Workstations ---------- 




Apollo 


Aegis 


Pascal 


Apple II 


DOS 3. 3 or ProDos 


6502 Assembler 


Atari ST Series 


GEM 


C 


Commodore 64 


DOS 


CROSS (or FORTH*) 


DEC Professional-350 


P/OS 


Bliss 


Honeywell L6/10 


MS-DOS 


MASM 


IBM PC family 


PC DOS 


Lattice C 


OS9/68000 Portable 


various 


Assembler 


Sirius 1/Victor 9000 


MS-DOS 


C 


TRS-80 Model 4 


TRSDOS 


ASM 


Tandy 2000 


MS DOS 


MASM 


TRS-80 I and III 


TRSDOS 


Z80 Ass. 


Minis and Mainframes - 






Cray-1, Cray-XMP 


CTSS 


Fortran-77 


Data General 


AOS /VS with MV/UX 


C 


DECSYSTEM-20 


TOPS -20 


MACRO- 20 


Honeywell 6000 


DTSS 


Virtual PL/ I 


Hewlett-Packard 3000 


MPE 


SPL 


[BM 370 Series 


UK/ CMS 


P 1 / VS 






X 0 V Li X ^ > M 


IBM 370 Series 


MTS 


Asm, Pascal 


i Sperry/Univac-1100 


EXEC 


Assembler 


j VAX 


VMS 


C 



Figure 5. Partial list of available KERM1T applications 



C. TERMINAL EMULATOR 

There are many types and makes of microcomputer available within the DOD 
community. Creating a way to transport graphic images among all of them would in- 
volve many problems. For this reason the selection of a microcomputer on which 
to base the emulation program is a critical decision point in this thesis research. 
This choice is dictated by the availability and cost of the microcomputer as well as its 
resident graphics handling capabilities. Why select the Heath/ Zenith Z- 100 over the 
IBM -PC? One of the greatest assets of the Z-100 computer is its high- resolution 
graphics capability which is made easy to use by the availability of powerful graphics 
statements in the Heath/Zenith (Z-BASIC) implementation of Microsoft BASIC [Ref. 
13: p. 77]. The following sections provide a short history and detailed analysis of this 
decision. 
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1. Z-100 versus IBM PC 

The IBM Personal Computer (PC) was introduced in late 1981. Because of 
IBM's success in the mainframe market place and the fact that their name was nearly 
synonymous with 'computer', it took the microcomputer world by storm and quickly 
became the industry standard. To become the 'standard' was an important devel- 
opment in the then new marketplace. The biggest change it introduced was the idea 
of third party software development. Until then almost all software was developed 
or sponsored for development by each computer manufacturer for exclusive use with 
their computer. 

The fact that other parties could now write and produce software for use 
on a set of new standard computers was both a blessing, for all the new microcom- 
puters that were to come, and a disaster for all that had already arrived. IBM had done 
something different in their computer architecture that made it vastly different [Ref. 
14: p. 47] from nearly all previously designed computers including the Z-100 . 

2. Differences 

The biggest differences appear in the physical hardware buss structure, the 
operating system and read only memory (ROM). The hardware buss that IBM se- 
lected on which to base thier PC's equipment architecture was not compatible with 
the S- 100 buss, the industry standard. This means that the physical connections are 
different from previous hardware implementations. These buss differences account 
for most of the hardware incompatibility while the ROM is to blame [Ref. 14: p. 48] 
for the rest. The ROM is called in order to access many of the hardware features 
required to accomplish interfacing between the software, the operating system and 
the microcomputer. 

Even a relatively simple application like word processing requires cursor 
movements and delete functions which must be accessed by the ROM. If a program 
goes to a memory location expecting to find an instruction and finds nothing or, 
even worse, a piece of data, it will not be able to execute the correct instruction. This 
will cause the program to stop. Even more complicated kinds of interface problems 
arise when performing graphics functions because so much interaction is required 
between screen instructions, memory storage and system functions to produce screen 
images. 

The actual image displayed is a product of the series of mapped or drawn lines 
of dots. Each dot is drawn (turned on or off) on the screen. The number of dots 
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available to turn on or off per inch are the picture elements (referred to as a 'pixels') 
and the higher the number of pixels, the higher the resolution of the graphics. The 
number of screen pixels addressable are characteristically between 640 X 200 and 640 
X 400, horizontally and vertically, respectively. All the different pixel combi- 
nations and sizes require different aspect ratio (height to width) calculations in order 
to correctly represent graphic images. Beyond these complications, within each system 
there are graphics modes (e.g. low, medium high, etc.) which correspond to different 
resolutions. Different microcomputer systems store the data and information required 
to describe the picture in different memory locations, which adds yet one more level 
of confusion. From this brief description of some of the variables, it can be seen that 
trying to write one software program, especially a graphics intensive one, which 
would apply to all microcomputers is an impossible task. 

3. Z- 100 Screen 

In the normal text mode, the Z-100 will display 25 lines of text at 80 characters 
per line. Each character is comprised of a matrix of 8 X 9 pixels. A quick and simple 
calculation leads to the screen resolution of 640 (horizontal) X 225 (vertical) dots which 
can be turned on or off to draw a picture. Although too complicated to address in 
great detail in this thesis, there is a process by which the display circuitry in the Z-100 
can address the pixels to provide a picture 400 lines across, instead of 225. This 
process is called interlacing because every other line is displayed in an alternating 
fashion. The price payed for this extra resolution is a flicker apparent to the human 
eye in this mode. Normally the screen is refreshed, or drawn over, 60 times every 
second. 15 In the interlace mode, the alternating portions of the screen are refreshed 
only 30 times a second, which can be seen by the naked eye. This gives the appearance 
of "flickering". 

4. Tektronix Screen 

The interlace mode would provide a much better quality (higher resolution) 
representation of the actual graphics quality if using that mode when emulating a 
Tektronix graphics terminal. The Tektronix screen format is a 1024 X 1024 pixel in- 
struction set, but the rectangular shape of the cathode ray tube (CRT) reduces the 
visual area to a 1024 X 780 pixel size. There are other differences between the lo- 
cation scheme for pixels on the Tektronix and the Z-100. Figure 6 below shows 

15 The 60 times a second is a result of the supply power of 60 Hz (60 cycles per second). 
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there is also a difference in the orientation of the screen's home or (zero, zero) starting 
point. 

The CRT graphics can be routed (saved) to a disk file or sent directly to a dot 
matrix printer [Ref. 14: p. 73] and printed with nearly the same resolution as the ori- 
ginal picture. 16 The real advantage of this will become apparent in the next section 
about the printer programs . 

5. Emulation Program 

There are a number of factors which must be discussed in order to attack 
the problem of creating a program which would display graphic information on 
microcomputers. The major factors to be considered are the language to use in program 
development, the type of data used to describe/create the drawings, the format and 
contents of the picture data file, and the actual drawing program itself. Each of these 
areas is further examined below. 

a. Language Selection 

The advantage of using a high level and more structured programming 
language than BASIC is that it would perhaps provide an easier avenue to approach 
the actual program coding. But built-in graphics statements are only available in the 
PC-DOS version of PASCAL, and there are only a few libraries of graphics subroutines 
available for C which are only for the IBM [Ref. 15: p. 71]. BASIC, on the other hand, 
is an old and reliable, if not omnipresent, language that is available on almost all gov- 
ernment- owned machines. Using BASIC's built-in graphics statements will ensure the 
program will run on all of the target microcomputers and can be easily changed as 
required by nearly anyone with a minimum set of programming skills. 

b. Tektronix Graphics Protocol 

One of the many standard graphics formats used widely is the Tektronix 
graphics terminal protocol. The high performance Tektronix 4010 series terminals 
will interface with many host graphics processing programs such as SAS/GRAPH, 
TELL-A-GRAF, GKS, VANGO, DI-3000, PLOT-10, DISSPLA and many more. 
There are commercial emulation software packages available for the IBM PC which 
emulate all the capabilities of the 4010 terminal except those that depend on the storage 

16 A common standard dot matrix printer like the OKIDATA has a 60 X 66 dot per inch 
printing pattern. When printed sideways at 9.5" x 6.5", this produces an area print of 627 X 
390 dots. Recall the dot per inch resolution of the CRT was 640 X 400 in the interleaving mode. 
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Screen Resolution and Orientation' 
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Figure 6. Differences between the Tektronix and Z-100 CRT. 

tube technology.17 These emulator programs are relatively inexpensive, but require 
a specific hardware upgrade^ to enhance the normal IBM graphics capability to a 
higher resolution range, which brings it closer to the normal resolution capa- 
bilities of the Z-100. • 



17 The storage tube technology referred to are the write thru and defocus attributes which 
are activated by escape sequence instructions. 

18 The hardware upgrades required are the Color Graphics Adapter (CG A), Enhanced 
Graphics Adapter (EGA) or other graphics enhancing computer hardware upgrade. 
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c . Drawing Program 

Utilizing the built-in graphics capabilities of the Z-100, the graphing 
protocol of the Tektronix terminal can be emulated using the drawing instruction 
statements in Z-BASIC. The approach is outlined in these five steps: 

1. Read the drawing instruction from the mainframe or other other graphics source. 

2. Calculate the equivalent proportional movement on the Z-100 screen. 

3. Draw (turn on or off) each vector of dot(s). 

4. See if there are more drawing instructions from the source system. 

5. Go to step (1) and continue until finish or end of data file. 

d. Implementation 

The emulator program, listed in Appendix F [Ref. 13: p. 80] was adapted 
easily for use with the DDN. The playback program, also listed in Appendix F and 
suggested in the same article, allows any picture to be saved to a disk file from the main 
emulator program and to be redrawn to the CRT. The program code itself is very 
well documented and a very detailed discussion of the program can be obtained from 
the original article if further information is required. The emulator can be adapted to 
nearly any system easily with only slight variation. 

e. Capabilities 

The emulation program was selected because it includes only the minimum 
set of capabilities required to complete the task of emulating a tektronlx graphics ter- 
minal. There are no extras to cloud the major emulation issues required to prove the 
LO-CO-GRAF system concept. The basic program includes a communications module 
which allows dialing from the keyboard if using an auto dial modem. The graphics data 
from a mainframe processing program can be captured (saved) on a disk on the 
microcomputer to be replayed/displayed onto the Z- 100 CRT. 

/. Picture Data File 

After the graphics source program is accessed, any picture screen can 
be savedl9 to a disk in about 50 kilobytes of disk storage space, which leaves enough 
room for the emulator program, the playback program and six picture files on a disk 
formatted with 360 K of storage. The advantage of this method of storage is that play- 
ing back the picture takes a very short time because it fills the video memory with the 

19 This process is actually reading each screen memory address and copying each byte from 
memory to a file named by the operator, thus creating a picture data tile. 
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data and does not have to redraw the picture vector by vector. With the picture (e.g. 
map, graph, etc.) redrawn and presented on the CRT, the next and last task of the 
LO-CO-GRAF process is producing a paper copy for use. 

D. SCREEN PRINTING 

Paper copies of maps, charts, and other graphics may never be replaced by other 
media. With all the computing and storage power available today there is still a reluc- 
tance to do away with the "file" or "working" copy. The LO-CO-GRAF system would 
not be complete without a means to print a paper copy of the graphics it produces. 

Saving the frame20 by capturing the video memory of the CRT to a disk file is 
the heart of the playback and screen printing function. Recall (para III.C.5.C.) the de- 
cision to write the map information to the screen and then save it as a pixel by pixel 
memory dump. This process maintains the best possible ’•esolution from the original 
vector drawings and now realizes the payoff for that decision. The last, and now easiest, 
task for the system is to simply dump the screen pixels to a printer. 

There are many screen dump programs available to accomplish this but the one 
chosen is licensed by the U. S. Government and applicable to many standard DOD 
printers. 

1. SCDMP 

SCDMP is a printing utility that allows reproduction of a complete video 
screen on a dot matrix printer, including both text and graphics, without having 
to exit the current program. The SCDMP program may be loaded manually 
(by entering SCDMP <cr>) or automatically, via 'autoexec.bat', into memory at the 
beginning of a session where it remains resident until needed. To print a desired sta- 
tionary screen or frame, simply press <SHIFT-F12>, which generates an interrupt-5 
and activates the screen dump. 

2. Options 

The SCDMP program allows a choice of which color bank of video RAM is 
dumped (if the Z-100 has all banks of color RAM installed). The number of 
video RAM (VRAM) banks installed in the computer is determined automatically 
by SCDMP upon initial load. For the color version, entering a <B> for blue, <R> 
for red, <G> for green, or <A> for all banks immediately after the 
< SHIFT-F12> will select the VRAM bank to be printed. If no character is entered, 

20 "Frame" is used here to describe the graphic and/or alphanumeric contents of the CRT 
screen. 
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< A> 11 banks is the default. If only one bank of color RAM is installed, only the 
green bank can be dumped. For use with LO-CO-GRAF, there is no need to change 
from the default since only the green bank is loaded with data from any saved map. 
SCDMP also allows multiple density printing for some printers. Entering an < H > 
immediately after the <SHIFT-F12> or color selection would cause the printer to 
use a higher density mode for printing. The default density is normal or standard 
density. The higher density switch will make the printout much darker. There are 
several other useful switch options which are explained in more detail in the SCDMP 
documentation.^ 

3. Printer Support 

The printers currently supported for U. S. Government use are the Epson 
MX/RX/FX Series with Graftrax, the Okidata Microline 83 A, and Zenith/ M PI 
99/150 Series. A dot matrix printer which is compatible with any of these may also 
be used. Only the printer control instructions need be the same. The control sequence 
information can be determined from the printer operating manual [Ref. 16]. Printing a 
paper copy is the last piece of the LO-CO-GRAF system. The next step is to put it all 
together and actually create, capture, save, playback, and print a map. The total system 
will be evaluated in the next chapter with attention given to any problems encountered. 



21 See Appendix G for specific information. 
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IV. ANALYSIS OF DATA 



This chapter investigates the actual steps required to obtain maps in a typical 
session using the Defense Data Network and provides an analysis of the graphics pro- 
ducts produced and the emulator performance. The session begins with accessing 
the DDN to obtain the KERMIT files necessary to establish a viable communi- 
cations network and ends with a final session showing how to use that network to 
transmit a map file. 

A. OBTAIN KERMIT 

The best way to show how the system works is to use it to promulgate itself. 
Assuming only a Knowledge of the system components and some basic skills operating 
microcomputers and any DDN terminal it is possible to see the power of 
LO-CO-GRAF in action. 

1. The DDN Session 

The following session on the DDN is a demonstration of how to obtain the 
KERMIT files necessary to establish a working communications network to handle 
file transfers between command components and terminals. The first step is to locate 
a DDN terminal and sign on to the command's account. A simple File Transfer Pro- 
tocol (FTP) to the Columbia University Center for Computing will facilitate down 
loading all the necessary files to get KERMIT. The session follows: 

* The star (*) below will indicate notes to the operator and provide details not 
otherwise available The <cr> will be used to indicate carriage return. 

* Sign on to the DDN to get the welcome message: 

WELCOME TO DDN. FOR OFFICIAL USE ONLY. TAC LOGIN REQUIRED. 

CALL NIC 1-800-235-3155 FOR HELP. 

MONTRY TAC 113 #: 61 
@0 3/103 

TAC Userid: XXXXX-XXXXX * Site Specific 

Access Code: XXXXXX * Site Specific 

Login OK 

TCP Trying. . . Open 

ISI-SYSTEM-A, T0PS-20 Monitor 6.1(4050) 

There are 31+15 jobs and the Load Average is 2. 20 
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************************************************************ 



THIS SYSTEM IS RESTRICTED TO UNCLASSIFIED INFORMATION ONLY. 
THE ENTRY OR COMMUNICATION OF CLASSIFIED DATA IS PROHIBITED. 



**** ** ********* ********* * ** **** *** *** ***** ^WpVp** ** ***** ****** 



After login, type "HELP ?" followed by a carriage return for 
a list of on-line help topics. 



* After login enter the following: 

(3 FTP CU20B.COLUMBIA.EDU 

* The system responds with: 

Connection opened (Assuming TYPE L 36, MODE S, STRU P) 

< CU20B.COLUMBIA.EDU FTP Server Process 5Z(46)-7 
at Fri 15-Jan-88 12: 28-EST 

CU20B. COLUMBIA. EDU> 

* Enter: 

LOGIN ANONYMOUS <cr> 

* The system will request a password: 

Password: 

* Enter GUEST <cr> and the response follows: 

< User ANONYMOUS logged in at Fri 15-Jan-88 12: 28-EST, job 207. 
CU20B. COLUMBIA. EDU> 

* At this point request access to the KERMIT disks : 

CD PK: <KERMIT> <cr> 

* The response will be: 

< Default name accepted. Send password to connect to it. 

CU20B. COLUMBIA. EDU> 

* Now enter DIR <cr> to see the list of files (it is very long) 

DIR <cr> 

< List started. 

PK: <KERMIT> 

A A ARE AD. ME. 6 
AAAUPD. HLP. 5 



AANETW. HLP. 29 * *This file is included as Appendix D 

« 

XXU. C. 2 

CU20B. COLUMBIA. EDU> 

* At this point just follow the instructions in appendix C and D to obtain the correct 
files and KERMIT is now in your DDN account for the Heath/Zenith Z-100. 

* to quit and get back to your home terminal is standard procedure from here: 

Enter BYE < cr> : 
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BYE <cr> 

< QUIT command received. Goodbye. 

FTP>QUIT 
@ LOGOUT 

Killed Job 39, User BISHOPR, TTY 162, at 15-Jan-88 12:33:46 
Used 0:00:08 in 0:07:54 
Host closing connection 
Closed 

2. KERMIT in Hand 

With a usable copy of KERMIT on site, one can set up a communications 
network between any other computer that has a copy of KERMIT. As can be seen by 
the simple session above, there are virtually no problems associated with obtaining the 
necessary files and the program itself is self documenting. The KERMIT program pro- 
vides virtually error free transmission for data files and other programs between com- 
puters. 

The KERMIT program is the central pivot for sending not only the map data 
files but for the terminal emulator, play back and printing programs which make up 
the LO-CO-GRAF system. 

B. TERMINAL EMULATOR 

Invoking the terminal emulator requires entering the program name if a compiled 
version is available. If not, then an interpreted version may be used but will run a little 
slower. To invoke an uncompiled version, enter Z-BASIC and then the program name. 
After loading the emulator it is necessary to access a source program for generating 
the graphics products. For this portion the DDN was again chosen. Using the Briefing 
Aid System (BAS) on the DDN as the remote source provided an excellent example 
of the networking capability of the LO-CO-GRAF system. 

A working session will demonstrate how to access the. graphics generating 
program but first it is necessary to put an instruction file in the DDN directory which 
identifies the type of terminal used.22 Enter and name a file that will reside in the di- 
rectory to provide connection instructions for the backend device protocol in the 
BAS. This file name will be requested during the graphics session. The data must 

be entered as follows: 

backend=( tektronix) ,device=(d,tty: ) 

» 

After the file is created on the DDN and put in the directory, the BAS program files 
can be used. 



22 Appendix H provides specific instruction for accessing the DDN with a Z-100 and then 
using the LO-CO-GRAF system. 
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TEKTRONIX 4006/4010 GRAPHICS TERMINAL EMULATOR 



BAUD : 1200 PARITY : N BITS : 8 



1SAVE 2FUTURE 3FUTURE 4CLS 5QUIT 6FUTURE 7CTRL-C 8X0FF 9XON 



Figure 7. Emulator Screen 

1. Emulator Screen Size 

After accessing the DDN, set the terminal screen size to 24 lines long. This 
will keep it from killing the program and dumping out of the emulator back to the op- 
erating system on the Z-100. The problem seems to stem from filling the screen with 
data or alphanumerics and running out of space. When running the emulator this 
problem can be avoided by clearing the screen before any major new operation. A 
preset function key (F-4) is programmed to do this easily. 

2. Emulator Session 

After invoking the emulator, the sign on the screen, as shown in Figure 7, ap- 
pears. Clear the screen before continuing and enter the correct codes to dial the DDN 

and sign on. This works very well with an auto- dial modem by entering: 
ATDTXXXXXXX *The phone number varies with location 

The next step was to access the program in the following manner: 

* Again signing on to the DDN 

WELCOME TO DDN. FOR OFFICIAL USE ONLY. TAC LOGIN REQUIRED. 



35 




* After complete login enter: 
(§DIR<LEVEL2> 

PS: <LEVEL2> 
2400-SLIDE. GPX. 1 



AIRROUTES. GPX. 1 * This slide is provided as example 

ETHIOPIAN-CONFLICT. GPX. 1 * Some of these slides are provided 

FALKLAND- ISLANDS. GPX. 1 * in appendix H 

HORMUZ. GPX. 1 
MEDIT. GPX. 1 

PACKET-RADIO-SLIDE. GPX. 6 
RHORMUZ. GPX. 1 

* Above is a list of maps available to be downloaded from the BAS in the level2 direc- 
tory. To download one just enter: 

<level2>Viewer <cr> 

The main menu will appear and ask for the name of the device instruction 
file23 and then which map to generate. An example of the AIRROUTES. GPX map 
is in Figure 8. As can be seen, there is no way to distinguish between the two colors 
that indicate the two routes. This is not a problem with most maps because a single 
color is usually all that is available. The quality is comparable to a similar map 
generated on the NPS IBM mainframe computer using DISSPLA's World Coast Utili- 
ties option. 

C. MAP QUALITY 

The resolution of maps currently being produced electronically is sufficient for small 
scale, large area planning. These maps remain highly dependent on the number of data 
points available for generating the cartographic projection. Figures 9 and 10 represent 
typical products of mainframe resident mapping programs. The differences are partially 
due to printer capability; Figure 9 being produced on an Epson-based dot matrix, while 
Figure 10 was done on IBM 3800 laser printer capable of 270 dpi. These maps are could 
be ideal for strategic and operational levels of command and staff planning. 

23 This is the file placed in the DDN directory above. 
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Figure 8. Example AIROUTES.GPX Map 



1. LO-CO-GRAF and Briefing Aid System maps 

There were many maps to choose from for this test and some of them are in 
Appendix I along with a comparative set of maps generated on the NTS mainframe, 
which are included at Appendix J. The maps that are filled in, like those in Figures 13 
through 15, require a very long time to draw; averaging approximately 30 minutes each. 
The long time is required because each line vector must be calculated and drawn 
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Figure 9. Map generated by Briefing Aid System/DDN: Area map of the North 

Sea region. 



seperateiy to fill in an area. Although this time is relatively long, it is not an unac- 
ceptable period. When the maps were saved to disk and played back later, it did not 
make a difference in redraw times whether they were filled in or not. The redraw times 
were very fast, three to six seconds. 
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Figure 10. Map generated by DISSPLA World Coast Utilities: Area map of the 
North Sea and English Channel region. 

2. DISSPLA maps 

The typical map generation times for DISSPLA was seventy seconds. The time 
for a metafile to generate a map from its stored data was thirty seconds, but was more 
dependent on system loading. The longest recall time for a metafile was 210 seconds in 
a program where DISSPLA used many of its self-correcting features. The maps would 
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be suitable for strategic and operational level planners, however possible tactical uses 
are negligible. The metafiles transport via any file transfer protocol and the DISSPOP 
option of DISSPLA can display them on an extremely wide selection of graphics devices. 
The times required to generate these maps were acceptable. Better cartographic resol- 
ution created by a greater number of data points could increase the times for map gen- 
eration, but this probably would also be in the acceptable range. 
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V. CONCLUSIONS AND RECOMMENDATIONS 



The premise of this thesis is that: (1) access to maps via electronic means is cur- 
rently feasible and desirable, and (2) combining a standard dot matrix printer with the 
Z-100 microcomputer (purchased en masse between 1982 and 1986) and developing a 
few software programs which could provide a low cost graphics and map generating ca- 
pability which would greatly enhance the command and control process. These premises 
were achieved. 

A. VALIDATION 

The goal of this thesis, to show that the Zenith Z-100 will emulate a Tektronix 
graphics terminal, has been validated. The specific C2 objective of electronically trans- 
ferring maps and charts has also been achieved. Another command and control tool has 
been developed which can be further exploited. 

1. Large Screen Displays 

The current cartographic representations used in situation rooms and command 
centers for their large screen displays lack resolution. The preliminary steps have been 
taken in this thesis to make maps and charts available at the desk of every microcom- 
puter user requiring them. The benefits are significant to the commander and decision 
makers, intelligence, logistics, and communications personnel. With the addition of 
more resources and research to microcomputer graphics emulation, operationally ori- 
ented personnel and tactical levels of command will soon benefit equally. An example 
of this is the current maps used in WWMCCS displays and in command centers which 
use other strategic and operational level cartographic tools. 

2. Simplicity' 

A self-imposed requirement to attain this command and control tool at no cost 
has been achieved. This constraint was levied in order to make it accessible to all DOD 
commands as soon as possible. The no-cost alternative for having a local graphics ter- 
minal capability is highly desirable. Many commands which have placed their Z- 100's 
on shelves, in storage, or marked for disposal could reconsider that decision. The variety 
of graphics products which can be displayed, sent, or received is very significant and will 
become more important to the C2 process in the future. The no-cost decision also lim- 
ited the number of options that could be considered to software already purchased by 
the DOD or in the public domain. 
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B. RECOMMENDATIONS FOR FUTURE EFFORTS 

The scope of this project was sufficient to occupy the available time. It did, how- 
ever, surface many future areas of endeavor to be expanded. Below are listed a few of 
the interest areas uncovered: 

1. User Friendly 

The requirement to be more user friendly will surface continuously until the 
machines are as smart as people are and will do what is required without being told. 
Specific areas which could use more smoothing are: (1) Map generating packages on 
mainframe computers operating interactively, requiring only page or screen dimensions, 
level of resolution, and location and scale of the map or chart, and (2) the graphics ter- 
minal emulator, though designed to be friendly, should not intimidate the user. Selection 
of devices and capabilities should be menu driven and include error and fault checking. 

2. Applications to Tactical Users/C2 Centers 

Access to tactical level maps and charts remains the real requirement. The only 
centralized source of this cartographic information continues to be DMA and NOAA. 
Therefore, DMA or NOAA must devise a system for accessing their digitized mapping 
databases and allowing the users to custom build their own maps and charts. A possible 
approach to solving the shortcoming of not having the ability to transfer maps and 
charts electronically, would be to develop programs for many microcomputers to con- 
struct and display the cartographic plots. The microcomputer would need to have a 
graphics capability sufficient for this type of display. The example of maps or charts 
required for a command and control center is given above. A more significant require- 
ment is the ability to pass tactical level maps. Many units will have ready brigades, 
specific ships, or air squadrons in an alert status. When these units are required to 
"fly-aw r ay", they possibly may not have gotten to the point on the logistics checklist for 
tactical maps. The necessary graphics products could be prepared for the unit and 
transmitted to it while in transit. Similarly, intelligence updates and other information 
could be transmitted as soon as available. 

3. NPS Applications 

The Naval Postgraduate School's academic program has many uses for 
cartographic products. For example, the National Security Affairs Department uses 
some of the microcomputer's map generation programs discussed in Chapter I. These 
are used for strategic level discussions and as aids in geographic analysis. The Admin- 
istrative Sciences Department uses similar products to allow graphical analysis of sta- 



42 



tistical data. The Meteorology and the Air-Ocean Science Department commonly use 
the map generation program maintained on the DEC mainframe computers at Fleet 
Numerical and Oceanographic Center across the highway. The biggest user of maps and 
charts would probably be the Operations Research Department, specifically the 
Wargaming and Analysis Laboratory. Their current system uses video disc technology 
to display maps in the Joint Theater Level System (JTLS) and low resolution digitized 
maps for Naval Warfare Integrated Simulation System/Integrated Battle Group Tactical 
Trainer (NWISS/IBGTT). 

a. Specific Uses for DISSPLA Maps 

One suggested area for further study is the generation of flat earth maps to 
use in battle planning or deployment exercises. These maps could be bounded and 
sized in a standard way, by latitude and longitude, so that they could be cut and 
pasted to expand as operational maneuvers move from one map section to another. 
This would be especially useful to those who must respond to crisis situations world 
wide but who have limited knowledge of world geography or no access to existing 
maps. 

b. Increased use of DISSPOP 

The ability to save graphics in a compressed version, a metafile, is very sig- 
nificant. Preparation by students or instructors could be made readily available and with 
little specialized training. More output device options would need to be added to the 
current DISSPOP selection. Examples of these could include IBM PC's with CGA, 
EGA, or Hercules upgrades added in. Most home computers with a significant graphics 
capability could also be included. 

c. NPS War Lab 

A desirable output of this thesis was to make the map generation program; 
and the Z-100 graphics terminal emulator, portable so they could be transferred into the 
Wargaming Laboratory. The communications package and screen dump routines would 
also have to be customized to equipment existing in the laboratory. This portion was 
not attempted due to lack of time. Significant equipment differences exist between the 
wargaming laboratory and the main computer center which would require reworking of 
all phases of this project. A partial listing of the necessary changes follows: 

1. The computer center uses an IBM mainframe, the War Lab uses a VAX computer. 

2. DISSPLA with the map generation option is maintained on-line with the computer 
center. The War Lab requires that advance notice be provided so DISSPLA, and 
the necessary operating environment for it, can be scheduled. 
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3. The map generation programs and its interactive version are written in VS Fortran 
which is IBM exclusive. The programs would need to be modified so they are 
compatible with Fortran 77 in the VAX environment. 

4. A different version of the communications program (KERMIT) would need to be 
employed. As the discussion in Chapter III indicates, the version of KERMIT to 
talk, between a VAX and almost any microcomputer is available. The protocols 
remain the same, which is the reason KERMIT, in particular, was chosen for use 
in this project. 

5. The screen dump program chosen for this project was designed with most of the 
industry standard printer protocols available. The correct version would need to 
be chosen for the printers connected to the Z- 100's in the War Lab. 

d. DOD distributed wargaming system 

A future addition to the NPS War Lab is a connection to the DOD Dis- 
tributed Network (DISNET) subnet for C3 research. This system will serve NPS and 
four other research and development centers and engineering activities. Gateways to 
other classified and unclassified capabilities on the DDN would have to be identified. 
The opportunity exists with this system to have available more expertise and, probably, 
a greater desire to access high resolution digitized maps and charts or, if desired, to de- 
velop tactical ones for specific circumstances. The use of electronically transmitted maps 
could prove to be valuable research in the C3 wargaming and evaluation networks. 
Research conducted to aid the command decision maker by overlayed maps or maps 
with imbedded symbology could also be conducted. 
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APPENDIX A. EXAMPLE PROGRAM SHOWING DISSPLA'S 
INTERACTIVE MAPPING CAPABILITY 



The following Fortran program uses DISSPLA's map generation option. It has 
been written to be user friendly and "sailor-proof'. The program needs to be performed 
at a graphics workstation which includes a TEK 618. In order to run this program on 
different equipment, some modification would be necessary. 

A. HOW TO RUN THE DISSPLA MAP GENERATOR 

After you have copied the following program you can generate any of the listed 
maps at any time you wish: 

NOTE: You must be using an NPS terminal that has a Tektronics 618 

graphics monitor attached . 

1. Enter "DISSPLA" The program will respond with a welcome message. 

2. When the program requests the name of the program you wish to run, enter the 
file name you have given this program and then press "PF- 10/22" to execute. 
There are other options at this point for help (PF-1/13), to quit (PF- 3/15), or 
to view or edit a map file (PF-4/16). 

3. After pressing the PF- 10/22 key (execute) you will see several messages, in- 
dicating compiler passes, flash across the screen. This will be followed by a mes- 
sage indicating what file deffinitions are in effect and asking you if you would like 
to execute the program with those deffinitions or exit. After DISSPLA calls 
up all the supporting programs, you will be asked to press the enter key to 
continue. This step loads the Fortran program to be executed and compiles it. 

4. The program has been written to guide you through the selection of a map to 
plot and plot it for you. You will then be asked to enter the name of the map you 
have chosen. As the data for the map is called from disk storage you will see 
the plot being generated on the TEK-618. After the map is plotted on the 
graphics monitor, you will receive a prompt on the IBM terminal monitor in- 
structing you to press "enter" to continue. If you want a hard copy of the map, you 
can press the HARD COPY button on the bottom of the graphics monitor first. 

B. INTERACTIVE MAP GENERATION FORTRAN PROGRAM 



C* "THE POWER OF DISSPLA's MAP PROJECTION OPTION" * MAP00030 
C* * MAP00040 
C* BRETTE WALKER * MAP00050 
C* GENE BISHOP * MAP00060 
C* ROB SABO * MAP00070 
C ************* *** ********************************* ********************** MAPO 0 080 
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c 

C INITIALIZE 

INTEGER CHOICE, ANSWER 
CHOICE = 0 
ANSWER = 0 
C 

C MENU 

WRITE (6.10) 

10 FORMAT ( f THIS PROGRAM DEMONSTRATES THE MAP GENERATION ',/ 

1' CAPABILITY OPTION OF THE DISSPLA PROGRAM. ') 

WRITE (6.20) 

20 FORMAT ( f CERTAIN MAPS HAVE BEEN PREPROGRAMMED INTO THIS ’ ,/ 

1' DEMONSTRATION AND ARE AVAILABLE FOR YOUR VIEWING ONLY ' ,/ 

2' ON THE TEK618 DISPLAY. ') 

25 WRITE (6,30) 

30 FORMAT (' PLEASE SELECT FROM THE MENU BELOW THE EXAMPLE MAP ' ,/ 

1 ' YOU WOULD LIKE TO VIEW. ' ) 

WRITE (6,40) 

40 FORMAT (' 

WRITE (6,50) 

50 FORMAT ( ' 1. 

WRITE (6.60) 

60 FORMAT ( 1 2. 

WRITE (6,70) 

70 FORMAT (' 3. 

WRITE (6,80) 

80 FORMAT (’ 4. 

WRITE (6,90) 

90 FORMAT (' 5. 

WRITE (6 92) 

92 FORMAT (' 6. 

WRITE (6.100) 

100 FORMAT ( f PLEASE ENTER YOUR CHOICE: 1,2, 3, 4, 5 OR 6.') 

READ *, CHOICE 
C 

C ERROR CHECK OF CHOICE 
C 

C IF THE CHOICE IS ONE OF THE ALLOWABLE CHOICES THEN CONTINUE 
IF (CHOICE. GT. 0. AND. CHOICE. LT. 7) GO TO 110 



MENU') 

NORTH AND SOUTH AMERICA. ' ) 
CARIBBEAN AREA. ' ) 

NORTHERN FLANK. ' ) 
MEDITERRANEAN AREA. ' ) 

JAPAN AREA. ’ ) 

QUIT. ' ) 



C ELSE IF AN ERRONEOUS CHOICE THEN REENTER CORRECT CHOICE 
WRITE (6,105) 

105 FORMAT ( ' YOU HAVE MADE AN INCORRECT ENTRY. ' ) 

GO TO 25 



C 

C CONTINUE 

110 IF (CHOICE. EQ. 1) 
IF (CHOICE. EQ. 2) 
IF (CHOICE. EQ. 3) 
IF (CHOICE. EQ. 4) 
IF (CHOICE. EQ. 5) 
IF (CHOICE. EQ. 6) 



CALL NSAMER 
CALL CARMAP 
CALL NORMAP 
CALL MEDMAP 
CALL JAPMAP 
GO TO 145 



C 

C TRY AGAIN? 

WRITE (6,120) 

120 FORMAT ( ’ WOULD YOU LIKE TO TRY AGAIN? 



') 



MAP0010C 

MAP0011C 

MAP0012C 

MAP0013C 

MAP 0014C 

MAP0015C 

MAP0016C 

MAP0017C 

MAP0018C 

MAP0019C 

MAP0020C 

MAP0021C 

MAP0022C 

MAP0023C 

MAP0024C4 

MAP00250 

MAP 00 2613 1 

MAP0027C 

MAP0 0 2 80I 

MAP00290 

MAP0030C 

MAP00310 

MAP00320 

MAP00330 

MAP00340 

MAP00350 

MAP00360 

MAP00370 

MAP00380 

MAP00390 

MAP00400 

MAP00410 

MAP00420 

MAP0 0 4 30 1 

MAP00440 

MAP00450 

MAP00460, 

MAP00470 

MAP00480 

MAP00490 

MAP00500 

MAP00510 

MAP00520 

MAP00530 

MAP00540 

MAP00550 

MAP00560 

MAP00570 

MAP00580 

MAP00590 

MAP00600 

MAP00610 

MAP00620 

MAP00630 

MAP00640 

MAPOO650 
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125 WRITE (6.130) 

130 FORMAT ( f ENTER 1 FOR YES OR 2 FOR NO. ’ ) 

READ *, ANSWER 

C 

C CHECKING INPUT FOR ERROR 

IF (ANSWER. GT. 0. AND. ANSWER. LT. 3) GO TO 140 
WRITE (6,135) 

135 FORMAT ( ' YOU HAVE MADE AN INCORRECT ENTRY. * ) 
GO TO 125 

C 

C CONTINUE BY CHECKING FOR YES OR NO 

C 

C CHECK FOR YES 

140 IF (ANSWER. EQ. 1) GO TO 25 

C 

C ELSE ANSWER IS NO AND PROGRAM IS EXITED 

145 WRITE (6.150) 

150 FORMAT ( f HAVE A NICE DAY. ') 

STOP 

END 



C 

C 

C 

C 

C 

C 

C 



C 

C 

C 

C 



SUBROUTINE FOR MAP OF NORTH & SOUTH AMERICA 

THIS SUBROUTINE WILL CREATE A MAP OF NORTH & SOUTH AMERICA INCLUDING 
CENTRAL AMERICA, HAWAII, AND THE CARRIBEAN 

SUBROUTINE NSAMER 
LEVEL 0 

CALL GRAPHICS DEVICE 

CALL TEK618 

CALL HWSCAL (’SCREEN*) 



LEVEL 1 



SET PAGE SIZE AND PROJECTION SPECIFICATIONS 



C 

C 

C 

C 

C 

C 

C 

c 

c 

c 

c 



A=ll 

CALL PAGE (A, 8. 5) 

CALL PROJCT (‘MERCA’) 

CALL MAPOLE (-120, 0. ) 

CALL AREA2D (10,8) 

LEVEL 2 

DEFINE MAP PARAMETERS 
CALL MAPGR (-180. ,30. ,10. ,-55. ,30. ,75. ) 

LEVEL 3 

CALLS FOR CARTOGRAPHIC DATA AND LEVEL OF RESOLUTION 
CALL MAPFIL ('COAS') 

RETURN TO LEVEL 2 
CALL ENDPL(O) 

RETURN 



MAP00660 
MAP00670 
MAP00680 
MAP00690 
MAP00700 
MAP007 10 
MAP00720 
MAP00730 
MAP00740 
MAP00750 
MAP00760 
MAP00770 
MAP00780 
MAP00790 
MAP00800 
MAP00810 
MAP00820 
MAP00830 
MAP00840 
MAP 00 850 
MAP00880 
MAP00890 
MAP00900 
MAP009 10 
MAP00920 
MAP00930 
MAP00940 
MAP00950 
MAP00960 
MAP00970 
MAP00980 
MAP00990 
MAP01000 
MAP01010 
MAP01020 
MAP01030 
MAP01040 
MAP01050 
MAP01060 
MAP01070 
MAP01080 
MAP01090 
MAP01100 
MAP01110 
MAP01120 
MAP01130 
MAP01140 
MAP01150 
MAP01160 
MAP01170 
MAP01180 
MAP01190 
MAP01200 
MAP01210 
MAP01220 
MAP01230 
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END MAP 012/ 

C MAP012; 

SUBROUTINE NORMAP MAPO 12! 

MAPO 12! 

THIS IS THE NORTHERN FLANK OF NATO MAP013( 

MAPO 13! 

THIS PROGRAM WILL GENERATE A THEATER LEVEL MAP OF THE NORTHERN MAP013: 

FLANK AND INCLUDES ALL THE SCANDINAVIAN COUNTRIES. MAP013: 

MAP013i 

LEVEL 0 MAP0131 

CALL GRAPHICS DEVICE MAP013( 

MAPO 131 

CALL TEK618 MAP013I 

MAPO 13! 

LEVEL 1 MAPO 141- 

SET PAGE SIZE AND PROJECTION SPECIFICATIONS MAPO 14. 

MAPO 14: 

CALL PAGE( 15. , 11. ) MAPO 14! 

CALL SCMPLX MAPO 14^ 

CALL PROJCT( 'MERCA' ) MAPO 14.' 

CALL MAPMDE('STRAI') MAP014( 

CALL AREA2D( 13. ,9. ) MAP0141 

CALLXNAMEC' ’,1) MAPO 14! 

CALL YNAMEC ’,1) MAPO 14! 

CALL XAXANG(0. ) MAP015! 

CALL HEADIN( ' NORTHERN FLANK OF NATO’ ,22, 1. 5 , 1) MAPO 15. 

MAPO 15 : 

LEVEL 2 MAPO 15: 

DEFINE MAP PARAMETERS MAPO 15^ 

MAPO 15! 

CALL MAPGR(-15. ,5. ,55. ,55. ,5. ,75. ) MAP015! 

MAPO 15; 

LEVEL 3 MAPO 15! 

CALLS FOR CARTOGRAPHIC DATA AND LEVEL OF RESOLUTION MAPO 15! 

MAP016! 

CALL MAPFIL( ' PEUR' ) MAP016! 

CALL MAPFIL( 'EURO' ) MAP016: 

CALL MAPFIL(' ASIA') MAP016: 

CALL MAPFIL( ' PASI ' ) MAP016* 

CALL FRAME MAPO 16! 

CALL DASH MAP016* 

CALL GRID( 1,1) MAP016! 

CALL MARKER(-l) MAP016! 

MAP016! 

RETURN TO LEVEL 2 MAP017! 

MAP017! 

CALL ENDPL(O) MAPO 17: 

MAP017.' 

RETURN MAPO 17^ 

END MAPO 17! 

MAPO 17! 

SUBROUTINE JAPMAP MAPO 17! 

THIS IS A MAP OF THE OPERATING AREAS AROUND JAPAN MAP018( 

MAP018' 

THIS PROGRAM WILL GENERATE A THEATER LEVEL MAP OF THE SEA OF MAP018: 

JAPAN. MAPO 18! 
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LEVEL 0 

CALL GRAPHICS DEVICE 
CALL TEK618 

LEVEL 1 

SET PAGE SIZE AND PROJECTION SPECIFICATIONS 

CALL PAGE( 15. ,11. ) 

CALL SCMPLX 

CALL PRO JCT( 'MERCA' ) 

CALL MAPMDE('STRAI') 

CALL AREA2D( 13. ,9. ) 

CALL XNAMEC 1 ,1) 

CALLYNAMEC ' ,1) 

CALL XAXANG( 0. ) 

CALL HEADINC ’JAPAN AND THE KURILE ISLANDS' ,28,1. 5,1) 
LEVEL 2 

DEFINE MAP PARAMETERS 
CALL MAPGR( 125. ,5. ,160. ,30. ,5. ,55. ) 

LEVEL 3 

CALLS FOR CARTOGRAPHIC DATA AND LEVEL OF RESOLUTION 

CALL MAPFILC’ASIA’) 

CALL MAPFILC'PASI') 

CALL FRAME 
CALL DASH 
CALL GRID( 1,1) 

CALL MARKER(-l) 

RETURN TO LEVEL 2 

CALL ENDPL(O) 

RETURN 

END 



SUBROUTINE MEDMAP 

THIS PROGRAM WILL GENERATE A THEATER LEVEL MAP OF THE 
MEDITERRANEAN SEA. 

LEVEL 0 

CALL GRAPHICS DEVICE 
CALL TEK618 

LEVEL 1 

SET PAGE SIZE AND PROJECTION SPECIFICATIONS 

CALL PAGE( 15. ,11. ) 

CALL SCMPLX 

CALL PRO JCT( 'MERCA' ) 



MAPO 1840 
MAP01850 
MAP01860 
MAPO 18 70 
MAP01880 
MAPO 1890 
MAP01900 
MAP019 10 
MAP01920 
MAP01930 
MAPO 1940 
MAPO 1950 
MAPO 19 60 
MAPO 19 70 
MAP01980 
MAPO 19 90 
MAP02000 
MAP02010 
MAP02020 
MAP02030 
MAP02040 
MAPO 2 050 
MAP02060 
MAP02070 
MAP02080 
MAP02090 
MAP02100 
MAP02110 
MAP02120 
MAP02130 
MAP02140 
MAPO 2 150 
MAP02160 
MAP02170 
MAP02180 
MAP02190 
MAP02200 
MAP02210 
MAPO 2220 
MAP02230 
MAP02260 
MAP02270 
MAP02280 
MAPO 2290 
MAP02300 
MAP02340 
MAP02350 
MAP02360 
MAP02370 
MAP02380 
MAP02390 
MAP02400 
MAP02410 
MAPO 2420 
MAP02430 
MAP02440 
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CALL MAPMDE( ' STRAI ' ) 

CALL AREA2D( 13. ,9. ) 

CALL XNAME( ' ',1) 

CALLYNAMEC' ’,1)- 
CALL XAXANG( 0. ) 

CALL HE AD IN ( 'MEDITERRANEAN SEA' , 17, 1. 5, 1) 

LEVEL 2 

DEFINE MAP PARAMETERS 
CALL MAPGRC-10. ,5. ,40. ,25. ,5. ,50. ) 

LEVEL 3 

CALLS FOR CARTOGRAPHIC DATA AND LEVEL OF RESOLUTION 

CALL MAPFILC 'PEUR' ) 

CALL MAPFILC 'EURO' ) 

CALL MAPFILC 'ASIA' ) 

CALL MAPFILC 'PASI') 

CALL MAPFILC 'PAFR' ) 

CALL MAPFILC 'AFRI' ) 

CALL FRAME 
CALL DASH 
CALL GRIDC 1 , 1) 

CALL MARKER(-l) 

RETURN TO LEVEL 2 

CALL ENDPL(O) 

RETURN 

END 



SUBROUTINE CARMAP 

THIS IS A MAP OF THE CARRIBEAN OPERATING AREAS 

THIS PROGRAM WILL GENERATE A THEATER LEVEL MAP OF THE CARIBBEAN 
SEA AND THE GULF OF MEXICO. ALL OF CENTRAL AMERICA IS INCLUDED. 

LEVEL 0 

CALL GRAPHICS DEVICE 
CALL TEK618 

LEVEL 1 

SET PAGE SIZE AND PROJECTION SPECIFICATIONS 

CALL PAGEC15. ,11. ) 

CALL SCMPLX 

CALL PROJCTC 'MERC A') 

CALL MAPMDEC' STRAI') 

CALL AREA2DC 13. ,9. ) 

CALL XNAMEC ' ',1) 

CALLYNAMEC' ',1) 

CALL XAXANGCO. ) 



MAP024! 

MAP024( 

MAP024', • 

MAP024* 

MAP024< 

MAP025C 

MAP025I 

MAP0252 

MAP0253 

MAP0254 

MAP025' 

MAP025*: 

MAP025 ; 

MAP025£ 

MAP025S 

MAP026C 

MAP0261 

MAP0262 

MAP0262 

MAP0264 

MAP0265 

MAP0266 

MAP0267 

MAP026S 

MAP0269 

MAP027C 

MAP0271 

MAP0272 

MAP0273 

MAP0274 

MAP0275 

MAP0276 

MAP0280 

MAP0281 

MAP0282 

MAP0283 

MAP0284 

MAP0285 

MAP0286 

MAP0287 

MAP0288 

MAP0289 

MAP0290 

MAP0291 

MAP0292 

MAP0293 

MAP0294 

MAP0295 

MAP0296 

MAP0297 

MAP0298 

MAP0299 

MAP0300 

MAP0301 

MAP0302 

MAP0303 
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CALL 


HEADINC ’ CARIBBEAN SEA' , 13, 1. 5, 1) 


MAP03040 

MAP03050 




LEVEL 2 


MAP03060 




DEFINE HAP PARAMETERS 


MAP03070 

MAP03080 


CALL 


MAPGRC-100. ,5. ,-60. ,5. ,5. ,35. ) 


MAP03090 

MAP03100 




LEVEL 3 


MAP03110 




CALLS FOR CARTOGRAPHIC DATA AND LEVEL OF RESOLUTION 


MAP03120 

MAP03130 


CALL 


MAPFIL( * PNOR* ) 
MAPFILC ’NORT’ ) 


MAP03140 


CALL 


MAP03150 


CALL 


MAPFILC ’PSOU’) 
MAPFILC ’SOUT’ ) 


MAP03160 


CALL 


MAP03170 


CALL 


FRAME 


MAP03180 


CALL 


DASH 


MAP03190 


CALL 


GRID( 1, 1) 


MAP03200 


CALL 


MARKER(-l) 


MAP03210 

MAP03220 




RETURN TO LEVEL 2 


MAP03230 

MAP03240 


CALL 


ENDPL(O) 


MAP03250 

MAP03260 


RETURN . 


MAP03270 


END 




MAP03280 
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APPENDIX B. DISSPLA MAP GENERATION PROGRAMS 



The following Fortran programs can be used by DISSPLA to generate maps. Some 
modification could be necessary in order to ensure compatibility to the mainframe and 
graphics terminals they would be run on. As written, they were developed using VS 
Fortran. The version of DISSPLA being used must include the World Coast Utilities 
Option and the DISSPOP option which causes compression and decompression of the 
map files. Table 2 lists the maps that can be generated by the VS Fortran/ DISSPLA 
programs and the pages they can be found on. 



Table 2. GUIDE TO DISSPLA MAPPING PROGRAMS 



Map description 


Page 


Carribean Operating Area 


53 


Northern Flank of NATO 


54 


North and South America 


55 


Washington, DC 


56 


World Mercator Projection 


57 


Cape Canaveral/ Kennedy Space Center 


59 


Japan and the Kurile Islands 


60 


Mediterranean Operating Area 


61 


North-West Europe 


62 
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THIS IS A MAP OF THE CARRIBEAN OPERATING AREAS 

THIS PROGRAM WILL GENERATE A THEATER LEVEL MAP OF THE CARIBBEAN 
SEA AND THE GULF OF MEXICO. ALL OF CENTRAL AMERICA IS INCLUDED. 

LEVEL 0 

CALL GRAPHICS DEVICE 
CALL COMPRS 

LEVEL 1 

SET PAGE SIZE AND PROJECTION SPECIFICATIONS 

CALL PAGE(15. ,11. ) 

CALL SCMPLX 

CALL PROJCT( ' MERC A* ) 

CALL MAPMDE( ' STRAI 1 ) 

CALL AREA2D( 13. ,9. ) 

CALL XNAMEC 1 ',1) 

CALL YNAMEC ’,1) 

CALL XAXANG( 0. ) 

CALL HEADIN( 'CARIBBEAN SEA' , 13 , 1. 5 , 1) 

LEVEL 2 

DEFINE MAP PARAMETERS 
CALL MAPGR(-100. ,5. ,-60. ,5. ,5. ,35. ) 

LEVEL 3 

CALLS FOR CARTOGRAPHIC DATA AND LEVEL OF RESOLUTION 

CALL MAPFIL( 'PNOR 1 ) 

CALL MAPFIL( 'NORT* ) 

CALL MAPFIL( 'PSOU') 

CALL MAPFIL( 'SOUT') 

CALL FRAME 
CALL DASH 
CALL GRID( 1 , 1) 

CALL MARKER(-l) 

RETURN TO LEVELS 2 , 1 , . AND 0 

CALL ENDPL(O) 

CALL DONEPL 

STOP 

END 



CAR00030 
CAR00040 
CAR00050 
CAR00060 
CAR00070 
CAR00080 
CAR00090 
CAR00100 
CAR00110 
CAR00120 
CAR00130 
CAR00140 
CAR00150 
CAR00160 
CAR00170 
CAR00180 
CAR00190 
CAR00200 
CAR00210 
CAR00220 
CAR00230 
CAR00240 
CAR00250 
CAR00260 
CAR00270 
CAR00280 
CAR00290 
CAR00300 
CAR003 10 
CAR00320 
CaR00330 
CAR00340 
CAR00350 
CAR00360 
CAR00370 
CAR00380 
CAR00390 
CAR00400 
CAR00410 
CAR00420 
CAR00430 
CAR00440 
CARO 04 50 
CAR00460 
CARO 0470 
CAR00480 
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THIS IS THE NORTHERN FLANK OF NATO NOROC 

NOROC 

THIS PROGRAM WILL GENERATE A THEATER LEVEL MAP OF THE NORTHERN NOROC 
FLANK AND INCLUDES ALL THE SCANDINAVIAN COUNTRIES. NOROC 

NOROC 

LEVEL 0 NOROC 

CALL GRAPHICS DEVICE NOROC 

NOROC 

CALL COMPRS NOROC 

NOROC 

LEVEL 1 NOROC 

SET PAGE SIZE AND PROJECTION SPECIFICATIONS NOROC 

NOROC 

CALL PAGE ( 15. ,11. ) NOROC 

CALL SCMPLX NOROC 

CALL PROJCT( ’MERCA’ ) NOROC 

CALL MAPMDEC ’ STRAI ' ) NOROC 

CALL AREA2D( 13. ,9. ) NOROC 

CALLXNAME(' ’,1) NOROC 

CALL YNAME(* ’,1) NOROC 

CALL XAXANGCO. ) NOROC 

CALL HE AD IN( ’NORTHERN FLANK OF NATO* , 22 , 1. 5 , 1) NOROC 

NOROC 

LEVEL 2 NOROC 

DEFINE MAP PARAMETERS NOROC 

NOROC 

CALL MAPGR(-15. ,5. ,55. ,55. ,5. ,75. ) NOROC 

NOROC 

LEVEL 3 NOROC 

CALLS FOR CARTOGRAPHIC DATA AND LEVEL OF RESOLUTION NOROC 

NOROC 

CALL MAPFIL( ’PEUR’) NOROC 

CALL MAPFIL( ’EURO’ ) NOROC 

CALL MAPFIL( ’ASIA’ ) NOROC 

CALL MAPFIL( ’ PAS I ' ) NOROC 

CALL FRAME NOROC 

CALL DASH NOROC 

CALL GRID( 1,1) NOROC 

CALL MARKER(-l) NOROC 

NOROC 

RETURN TO LEVELS 2, 1 5 AND 0 NOROC 

NOROC 

CALL ENDPL(O) NOROC 

CALL DONEPL NOROC 

STOP NOROC 

END NOROC 
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THIS PROGRAM WILL CREATE A MAP OF NORTH & SOUTH AMERICA INCLUDING 
CENTRAL AMERICA, HAWAII, AND THE CARRIBEAN 

LEVEL 0 

CALL GRAPHICS DEVICE 
CALL COMPRS 

CALL HWSCAL ( * SCREEN* ) 

LEVEL 1 

SET PAGE SIZE AND PROJECTION SPECIFICATIONS 

A=ll 

CALL PAGE (A, 8. 5) 

CALL PROJCT ('MERCA') 

CALL MAPOLE (-120, 0. ) 

CALL AREA2D (10,8) 

LEVEL 2 

DEFINE MAP PARAMETERS 
CALL MAPGR (-180. ,30. ,10. ,-55. ,30. ,75. ) 

LEVEL 3 . * 

CALLS FOR CARTOGRAPHIC DATA AND LEVEL OF RESOLUTION 

CALL MAPFIL ('COAS') 

RETURN TO LEVEL 2 

CALL ENDPL(O) 

RETURN TO LEVEL 1 

CALL DONEPL 

RETURN TO LEVEL 0 

STOP 

END 



NSA00010 

NSA00020 

NSA00030 

NSA00040 

NSA00050 

NSA00060 

NSA00070 

NSA00080 

NSA00090 

NSA00100 

NSA00110 

NSA00120 

NSA00130 

NSA00140 

NSA00150 

NSA00160 

NSA00170 

NSA00180 

NSA00190 

NSA00200 

NSA00210 

NSA00220 

NSA00230 

NSA00240 

NSA00250 

NSA00260 

NSA00270 

NSA00280 

NSA00290 

NSA00300 

NSA00310 

NSA00320 

NSA00330 

NSA00340 

NSA00350 

NSA00360 

NSA00370 

NSA00380 

NSA00390 

NSA00400 
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THIS IS A MAP GENERATED TO COMPARE RESOLUTION BETWEEN DISSPLA DCMO' 

GENERATED MAPS AND OTHER DIGITIZED MAPPING PROGRAMS. DCMO' 

DCMO' 

THIS IS A MAP OF THE WASHINGTON DC AREA DCMO' 

DCMO’ 

LEVEL 0 DCMO' 

CALL GRAPHICS DEVICE DCMO 

DCMO' 

CALL COMPRS DCMO 

DCMO 

LEVEL 1 DCMO 

SET PAGE SIZE AND PROJECTION SPECIFICATIONS DCMO 

DCMO 

CALL PAGEC8. 5,11. ) DCMO 

CALL SCMPLX DCMO 

CALL PROJCT( 'MERC A' ) DCMO 

CALL MAPMDE(’STRAI') DCMO 

CALL AREA2D( 6. , 8 . ) DCMO 

CALL XNAME( ' ’,1) DCMO 

CALL YNAMEC ’,1) DCMO 

CALL XAXANG(0. ) DCMO 

CALL HEADIN( ’WASHINGTON DC AREA* ,18,1. 5,1) DCMO 

DCMO 

LEVEL 2 DCMO 

DEFINE MAP PARAMETERS DCMO 

DCMO 

CALL MAPGR(-78. ,0. 5,-76. ,38. ,0.5,40. ) DCMO 

DCMO 

LEVEL 3 DCMO 

CALLS FOR CARTOGRAPHIC DATA AND LEVEL OF RESOLUTION DCMO 

DCMO 

CALL MAPFIL( 'PNOR' ) DCMO 

CALL MAPFIL( ’ NORT' ) DCMO 

CALL MAPFILC’USAH') DCMO 

CALL FRAME DCMO 

CALL DASH DCMO 

CALL GRID( 1,1) DCMO 

CALL MARKER(-l) DCMO 

DCMO 

RETURN TO LEVEL 2 DCMO 

DCMO 

CALL ENDPL(O) DCMO 

DCMO 

RETURN TO LEVEL 1 DCMO 

CALL DONEPL DCMO 

DCMO 

RETURN TO LEVEL 0 DCMO 

DCMO 

STOP DCMO 

END ... • DCMO 
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The following program will generate a world map. 







DIMENSION DAT( 72,46) ,RHITE( 72,46) 


WLD000 10 






COMMON WORK(5000) 


WLD00020 






CALL COMPRS 


WLD00030 


c 






WLD00040 






DO 10 N=12, 72, 12 


WLD00050 






M=N-11 


WLD00060 






READ( 10,1000) ( ( DAT( I , JJ) , I=M , N) , JJ=1 , 46) 


WLD00070 




1000 


F0RMAT(F6. 0,11F5. 0) 


WLD00080 




10 


CONTINUE 


WLD00090 






DO 11 J=2,45 


WLD00100 






JP1=J+1 


WLD00110 






JM1=J-1 


WLD00120 






DO 11 1=1,72 


WLD00130 






IP1=M0D( 1,72) 


WLD00140 






IM1=M0D( 1+70 , 72)+l 


WLD00150 






S=0. 90 


WLD00160 






RHITE( I , J)=( 1. -S)*DAT( I , J)+( S/4. )*(DAT( IM1 , J)+DAT( IP1 , J) + 


WLD00170 




*DAT( I , JP 1 ) +DAT( I , JM1 ) ) 


WLD00180 




11 


CONTINUE 


WLD00190 






DO 12 1=1,72 


WLD00200 






RHITE( I , 1)=DAT( 1,1) 


WLD00210 




12 


RHITE( I ,46)=DAT( 1,46) 


WLD00220 


c 






WLD00230 






CALL BLOWUP (2.2) 


WLD00240 






CALL BASALF (’STAND 1 ) 


WLD00250 






CALL MIXALF (’L/CSTD 1 ) 


WLD00260 


c 






WLD00270 






CALL PR0JCT ( 1 AIT0F* ) 


WLD002G0 


c 




FOR AITOFF PROJECTION 


WLD00290 






CALL PAGE (10. 0,8.0) 


WLD00300 


c 




SET PAGE FOR VIEWGRAF 


WLD00310 






CALL AREA2D (8. 5,4. 0) 


WLD00320 


c 






WLD00330 






CALL XNAME (' 1 ,1) 


WLD00340 






CALL YNAME ( 1 ’ ,1) 


WLD00350 






CALL SCMPLX 


WLD00360 
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CALL HEADIN (’THE WORLD? ’ , 100, 1. 5 , 1) 


WLD00370 


c 






WLD00380 




99 


CALL YAXANG (0. ) 


WLD00390 


c 






WLD00400 






CALL MAPGR (-300. ,30. ,60. ,-90. ,30. ,90. ) 


WLD00410 






CALL GRID (1,1) 


WLD00420 






CALL MAPFIL (’HERSHEY') 


WLD00430 






CALL FRAME 


WLD00440 






CALL HEIGHT(0. 05) 


WLD00450 






CALL COMPLX 


WLD00460 






CALL BCOMON(5QOO) 


WLD00470 


c 






WLD00480 
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Fortran program WLDPLT continued. 



CALL C0NMAK( RHITE ,72,46,' SCALE ' ) WLDOOf 

CALL CONMAK( RHITE ,72,46,' SCALE ' ) WLDOOt 

C PLOT SMOOTHED CONTOURS WLDOOf 

CALL CONLIN (0 ,’ SOLID' ,' LABELS' , 1,5) WLDOOf 

CALL C0NANG(90. ) WLDOOf 

CALL RASPLN(0. 25) WLDOOf 

CALL CONTUR( 1 , ' LABELS ' , ' DRAW ' ) WLDOOf 

CALL COMPLX WLDOOf 

CALL HEIGHT(. 2) WLDOOf 

CALL MESSAG( 'DISSPLA MAP$' ,100,3. 5, -1. ) WLDOOf 

CALL RESET( 'COMPLX' ) WLDOOf 

CALL RESET( 'HEIGHT' ) WLDOOf 

CALL ENDPL(O) WLDOOt 

CALL DONEPL WLDOOt 

STOP WLDOOt 

END WLDOOt 
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o o o o o ono oono oooo oooo oooooooo 



THIS IS A MAP GENERATED TO COMPARE RESOLUTION BETWEEN DISSPLA 
GENERATED MAPS AND OTHER DIGITIZED MAPPING PROGRAMS. 

THIS IS A MAP OF THE KENNEDY SPACE CENTER/CAPE CANAVERAL AREA 

LEVEL 0 

CALL GRAPHICS DEVICE 
CALL COMPRS 

LEVEL 1 

SET PAGE SIZE AND PROJECTION SPECIFICATIONS 

CALL PAGE(11. ,8. 5) 

CALL SCMPLX 

CALL PROJCTC 'MERCA' ) 

CALL MAPMDE( ' STRAI ’ ) 

CALL AREA2D( 8 . ,6. ) 

CALL XNAME( ' ’,1) 

CALL YNAMEC ’,1) 

CALL XAXANG( 0. ) 

CALL HEADIN( ' CAPE CANAVERAL FLA 1 , 18 , 1. 5 , 1) 

LEVEL 2 

DEFINE MAP PARAMETERS 
CALL MAPGR(-81. ,0. 5,-80. ,28. ,0. 5,29. ) 

LEVEL 3 

CALLS FOR CARTOGRAPHIC DATA AND LEVEL OF RESOLUTION 

CALL MAPFIL( ’PNOR* ) 

CALL MAPFILC’NORT* ) 

CALL MAPFIL(’USAH’) 

CALL FRAME 
CALL DASH 
CALL GRID( 1,1) 

CALL MARKER(-l) 

RETURN TO LEVEL 2 

CALL ENDPL(O) 

RETURN TO LEVEL 1 
CALL DONEPL 

RETURN TO LEVEL 0 

STOP 

END 



EZM00010 

EZM00020 

EZM00030 

EZM00040 

EZM00050 

EZM00060 

EZM00070 

EZM00080 

EZM00090 

EZM00100 

EZM00110 

EZM00120 

EZM00130 

EZM00140 

EZM00150 

EZM00160 

EZM00170 

EZM00180 

EZM00190 

EZM00200 

EZM00210 

EZM00220 

EZM00230 

EZM00240 

EZM00250 

EZM00260 

EZM00270 

EZM00280 

EZM00290 

EZM00300 

EZM00310 

EZM00320 

EZM00330 

EZM00340 

EZM00350 

EZM00360 

EZM00370 

EZM00380 

EZM00390 

EZM00400 

EZM00410 

EZM00420 

EZM00430 

EZM00440 

EZM00450 

EZM00460 

EZM00470 

EZM00480 

EZM00490 

EZM00500 
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non oooo oooo oooo oooooooo 



THIS IS A MAP OF THE OPERATING AREAS AROUND JAPAN JAPOO 

JAP 00 

THIS PROGRAM WILL GENERATE A THEATER LEVEL MAP OF THE SEA OF JAPOO 

JAPAN. JAPOO 

JAPOO 

LEVEL 0 JAPOO 

CALL GRAPHICS DEVICE JAPOO 

JAPOO 

CALL COMPRS JAPOO 

JAPOO 

LEVEL 1 JAPOO 

SET PAGE SIZE AND PROJECTION SPECIFICATIONS JAPOO 

JAPOO 

CALL PAGE(8. 5,11. ) JAPOO 

CALL SCMPLX JAPOO 

CALL PROJCT( ’MERC A* ) JAPOO 

CALL MAPMDE( ' STRAI ’ ) JAPOO 

CALL AREA2D( 6. ,8. ) JAPOO 

CALLXNAMEC ’,1) JAPOO 

CALLYNAMEC' ’,1) JAPOO 

CALL XAXANG(0. ) JAPOO 

CALL HEADIN( ' JAPAN AND THE KURILE ISLANDS’ ,28, 1. 5, 1) JAPOO 

JAPOO 

LEVEL 2 JAPOO 

DEFINE MAP PARAMETERS JAPOO 

JAPOO 

CALL MAPGR( 125. ,5. ,160. ,30. ,5. ,55. ) JAPOO 

JAPOO 

LEVEL 3 JAPOO 

CALLS FOR CARTOGRAPHIC DATA AND LEVEL OF RESOLUTION JAPOO 

JAPOO 

CALL MAPFIL( ' ASIA’ ) JAPOO 

CALL MAPFIL( ’ PASI ’ ) JAPOO 

CALL FRAME JAPOO 

CALL DASH JAPOO 

CALL GRID( 1 , 1) JAPOO 

CALL MARKER(-l) JAPOO 

JAPOO 

RETURN TO LEVELS 2, 1, AND 0 JAPOO 

JAPOO 

CALL ENDPL(O) JAPOC 

CALL DONEPL JAPOO 

STOP JAPOO 

END JAPOO 
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ooo oooooooo noon oooooo 



THIS PROGRAM WILL GENERATE A THEATER LEVEL MAP OF 
MEDITERRANEAN SEA. 

LEVEL 0 

CALL GRAPHICS DEVICE 
CALL COMPRS 

LEVEL 1 

SET PAGE SIZE AND PROJECTION SPECIFICATIONS 

CALL PAGE( 15. ,11. ) 

CALL S CMP LX 

CALL PROJCTC ’MERCA’ ) 

CALL MAPMDE(’STRAI') 

CALL AREA2D( 13. ,9. ) 

CALLXNAMEC ’,1) 

CALLYNAMEC’ ’,1) 

CALL XAXANG( 0. ) 

CALL HEAD IN( ’MEDITERRANEAN SEA’ , 17, 1. 5 , 1) 

LEVEL 2 

DEFINE MAP PARAMETERS 
CALL MAPGRC-10. ,5. ,40. ,25. ,5. ,50. ) 

LEVEL 3 

CALLS FOR CARTOGRAPHIC DATA AND LEVEL OF RESOLUTION 

CALL MAPFILC ’PEUR') 

CALL MAPFIL(’EURO’) 

CALL MAPFIL( ' ASIA’ ) 

CALL MAPFILC ’ PASI ’ ) 

CALL MAPFILC ’PAFR’) 

CALL MAPFILC ’AFRI* ) 

CALL FRAME 
CALL DASH 
CALL GRIDC 1,1) 

CALL MARKERC-1) 

RETURN TO LEVELS 2, 1, AND 0 

CALL ENDPL(O) 

CALL DONE PL 

STOP 

END 



MED00030 

MED00040 

MED00070 

MED00080 

MED00090 

MED00100 

MED00110 

MED00120 

MED00130 

MED00140 

MED00150 

MED00160 

MED00170 

MED00180 

MED00190 

MED00200 

MED00210 

MED00220 

MED00230 

MED00240 

MED00250 

MED00260 

MED00270 

MED00280 

MED00290 

MED00300 

MED00310 

MED00320 

MED00330 

MED00340 

MED00350 

MED00360 

MED00370 

MED00380 

MED00390 

MED00400 

MED00410 

MED00420 

MED00430 

MED00440 

MED00450 

MED00460 

MED00470 

MED00480 

MED00490 

MED00500 
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o o o 00000000 000000000 



THIS PROGRAM WILL GENERATE A THEATER LEVEL MAP OF NORTH-WEST EUROPE UKMOC 



UKMOC 

LEVEL 0 UKMOC 

CALL GRAPHICS DEVICE UKMOC 

UKMOC 

CALL COMPRS UKMOC 

UKMOC 

LEVEL 1 UKMOC 

SET PAGE SIZE AND PROJECTION SPECIFICATIONS UKMOC 

UKMOC 

CALL PAGE(8. 5,11. ) UKMOC 

CALL S CMP LX UKMOC 

CALL PROJCT( 1 MERCA 1 ) UKMOC 

CALL MAPMDE( ' STRAI ' ) UKMOC 

CALL AREA2D( 6. , 8 . ) UKMOC 

CALL XNAMEC ',1) UKMOC 

CALL YN AME(' ',1) UKMOC 

CALL XAXANG(0. ) UKMOC 

CALL HEADIN( 1 NORTH-WESTERN EUROPE ' , 20 , 1. 5 , 1) UKMOC 

UKMOO 

LEVEL 2 UKMOO 

DEFINE MAP PARAMETERS UKMOO 

UKMOO 

CALL MAPGRC-10. ,5. ,15. ,45. ,5. ,62. ) UKMOO 

UKMOO 

LEVEL 3 UKMOO 

CALLS FOR CARTOGRAPHIC DATA AND LEVEL OF RESOLUTION UKMOO 



UKMOO 

UKMOO 

UKMOO 

UKMOO 

UKMOO 

UKMOO 

UKMOO 





RETURN TO LEVELS 2, 1, AND 0 


UKMOO 

UKMOO 


CALL 


ENDPL(O) 


UKMOO 

UKMOO 


CALL 


DONEPL 


UKMOO 


STOP 




UKMOO 


END 




UKMOO 



CALL MAPFILC’PEUR’) 
CALL MAPFIL(’EURO') 
CALL FRAME 
CALL DASH 
CALL GRID( 1 , 1) 

CALL MARKER(-l) 
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APPENDIX C. KERMIT ON-LINE HELP FILES 



This is a printout of a help file which is resident on the Columbia University Computer. 
It is updated about once a year. This version is accurate to 28 Jan 88. 



COLUMBIA UNIVERSITY KERMIT DISTRIBUTION 

This file explains what files are in the Kermit distribution and gives the naming 
conventions for them. 

If you are reading this from a handout supplied with a Kermit distribution tape, 
please note that this information might not be quite up to date — there may be files on 
the tape that are not listed here. The copy of this file, AAFILES.HLP, on the tape 
might be more current. 

The file AAFILx.DIR contains an up-to-date alphabetical directory listing of 
all the files in the respective Kermit distribution area (KER:, Tape A; K2:, Tape B; 
K3:, Tape C; etc.) — one such file is created in each area by a nightly batch job (x is 
A, B, C, etc). The directory listing supplied on paper with your tape should reflect 
exactly which files are on the tape, and in what order. 

The Kermit distribution areas include all the versions of Kermit which are in our 
possession. The files have names of the form 

NAME.TYPE 

where NAME is the name of file, and TYPE is its type 
(program source, documentation, executable core image, 
etc). No NAME is more than 9 characters long (the 
maximum accepted by VAX/ VMS), and every NAME starts with 
a letter and is unique in the first 6 characters (the 
maximum under TOPS-IO, RSTS/E, etc). On TOPS- 10 BACKUP 
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Interchange tapes, names longer than 6 will be truncated 
to 6. No type is longer than 3 characters. NAME and 
TYPE are separated by a period. 



* Types 

The files types don't follow a strict convention because the hies originate on so many 
different systems. But there are some patterns; here are some commonly used file types 



For Text Files: 



. BLD - Instructions for building 

. BWR - A "beware” file, listing known bugs, limitations, 
or other problems 

.DIF - Differences (produced by file comparison 
program) 

.DOC - Documentation (usually long) 

. HLP - Help message ( like DOC but usually shorter) 

. INS - Installation instructions 
. MAN - A manual 

.MEM - Documentation ("memo") produced by DEC Runoff 
. MSG - A text or mail message of some kind 
.MSS - Scribe text formatter source (for some of the 
.DOC files) 

.NR - Nroff text formatter source 
. RNH - Runoff text formatter source for .HLP files 
. RNO - Runoff text formatter source for .MEM files 
. TEX - TeX source 

.TXT - Text (usually shorter, sometimes in electronic 
mail message format) 

. UPD - Program update history 
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For Program Source: 



. A - Assembler 
. A68 - Algol-68 
. A86 - 8086 assembler 
. ADA - Ada 
.ALG - Algol-60 
. ASM - Assembler 
. B - B language 
. BAS - Basic 
.BLI - Bliss 

.BOO - "boo" format printable encoding of object or executable program 
. C - C language 
. CLU - CLU language 
. F - Fortran (Unix) 

. F77 - Fortran-77 
. FOR - Fortran 
. FTN - Fortran 

. H - Header file for C or ASM program 

. H86 - 8086 hexadecimal encoding of object or executable program 
.HEX - Hexadecimal encoding of object or executable program 
. HQX - "binhex" encoding of object or executable program 
. LSP - Lisp source code 
.MAC - Macro assembler 
. MAR - VAX assembler 
. PAS - Pascal 
. PL1 - PL/I 
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For Program Source fcon’t"): 



. PLC - PL/C 
. PLI - PL/ I 
. PLM - PL/M 

. REQ - VAX "require” (header) file 
. SAI - Sail 



. SCR - A FORTH "screen” 
. SRC - Source program 



For Svstem or Command Files: 



. BAV - A batch control file (e. g. for MS-DOS) 

. CMD - A command file of some kind 

.COM - VAX or PDP-11 DCL command file 

. CTL - A batch control file (e. g. for DEC-10/20) 

. INI - Initialization command file 

. JCL - Job control language (e. g. for Harris) 



* Prefixed File Names: 

The file names for files associated with each implementation of Kermit are prefixed 
by a Few characters denoting the implementation. Although the files are kept in 
separate areas, each prefix is unique among all the Kermit files, so that areas can be 
combined into a single area without any confusion. The following are presently used, 
(Items marked with asterisk have fuller explanations below): 
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--"micros'* (tape A } 



Prefix Machine(s) 


Operating System 


Language 


APP 


Apple II 


DOS 3. 3 or ProDos 


6502 Asm 


AST 


Atari ST Series 


GEM 


C 


ATA 


Atari Home Computer 


DOS 


Action! 


C64 


Commodore 64 


DOS 


CROSS 


*C86 


8086/8088 (see below) 


CP/M-86 


ASM86 


cc 


TRS-80 Color Computer 


Disk-Extended Color 


BASIC EDTASM 


*CP4 


8080,8085, Z80(see below) CP/M-80 


LASM 


*CPM 


8080 , 8085 , Z80 -- obsolete, see below -- 




CX 


Experimental new release of CP/M-80 Kerrait 


LASM 


K6 


CS9/68000 Portable 


various 


Assembler 


M4 


TRS-80 Model 4 


TRSDOS 


ASM 


*MS 


Various (see below) 


MS-DOS or PC -DOS 


MASM 


QK 


(various, see below) 




Turbo Pascal 


TA2 


Tandy 2000 


MS DOS 


MASM 


TRS 


TRS-80 I and III 


TRSDOS 


Z80 Ass. 


TR2 


TRS-80 Model II 


TRSDOS 


Z80 Ass. 


WIN 


IBM PC, etc 


MS-DOS w/MS -Windows 


Microsoft C4. 0 


WK 


IBM PC family 


PC DOS 


Lattice C 



* See below for notes about MS-DOS and CP/M Kermits. 
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--’’mainframes' 1 (Tape B) -- 



Prefix Machine(s) 



Operating System Language 



*CK 

*CK 

*CK 

*CK 

*CK 

*CK 

CM2 

IK 

K10 

*K11 

*K11 

K20 

MP 

*TSO 

*TS2 

*TS3 

*TSN 

UX 

*VMS 



VAX, SUN, many others UNIX 
VAX VMS 

Apple Macintosh Mac OS 

Commodore Amiga AmigaDOS/ Intuition 

Data General MV Series AOS/VS 



Apollo 

IBM 370 Series 

IBM 370 Series 

DECsystem-10 

DEC PDP-11 

DEC PDP-11 

DECSYSTEM-20 

DEC PDP-11 

IBM 3 70 -series /3 705 



Aegis 
VM/CMS 
VM/CMS 
TOPS -10 

RSX11 , RSTS/E , RT1 1 , TSX 
P/OS, Pro/RT, IAS 3.1 
TOPS -20 
MUMPS (M/ll) 

MVS/TS0 



IBM 3 7 0-series /Series 1 MVS/TS0 
IBM 370 -series /3 708 MVS/TS0 
IBM 370 -series/3 705 MVS/TSO 
Old, old, small Unix Kermit 
VAX VMS 



C 

C 

C 

C 

C 

C 

Pascal/VS 
IBM Ass. 

MACRO- 10 
MACRO- 11 
MACRO- 11 
MACRO -20 
MUMPS 
Assembler 

Pascal/VS , PL/I , etc. 
Assembler 
Ass. /ALP 
C 

Bliss-32 



* C-Kermit (Prefix CK, Tape B): 



C-Kermit is a transportable version of Kermit written in the C language. It is 
composed of many modules, some system- independent, some system- specific. C- 
Kermit has been implemented on many systems, some "mainframes" and some 
"micros". In particular, the Unix version runs on machines ranging from large IBM 
mainframes to VAX and other minicomputers to small PC's, and Kermit programs for 
the Apple Macintosh, the Commodore Amiga, VAX/VMS, DG AOS/VS, Apollo 
Aegis, CDC VX/VE, and many other systems can also be generated from C-Kermit. 
All the C-Kermit source files are kept together on tape B to avoid the problems that 
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would be introduced by splitting up the files or keeping duplicate copies. See the file 
CKAAAA.HLP for an explanation of the file naming conventions for C-Kermit. 

* The Kll files include support for RSX, RSTS, RT11, TSX + , IAS, 

and P/OS — See K111NS.DOC for details. 

* The VAX/VMS Bliss version is also provided in MACRO-32 (.MAR) 

source form for those sites that do not have a Bliss 

compiler, as well as in a hexadecimal encoding of the task 

image. YOU DON'T NEED TO HAVE BLISS IN ORDER TO RUN THIS 

VERSION. See VMSAAA.HLP. 

* Among the TSO Kermits, you should probably try the TSN version 

first. The TSO versions (one for linemode, a separate one 
for Series/ 1 -style 3270 emulation) are very old and 
primitive. The Pascal version requires a Pascal compiler 
and supports only linemode connections. The TSN version, 
from NTH, supports only linemode connections, but includes 
many advanced features. There's also version with the 
prefix TS3, which supports the 3708 front end. Many of 
these will be replaced by "portable 370" Kermit soon, under 
prefix IKO and IKT. 

For VM/CMS, please try the new IK*.* version. This is "portable 370" Kermit, 
which is a very advanced Kermit implementation, to which support for other IBM 370 
operating systems, like MVS/TSO, DOS/VSE, MTS, MUSIC, etc, should be easy to add. 
It supports most of the advanced Kermit options (long packets, etc), and both line mode 
and full screen connections. 
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-- Less popular micros Sc works tat ions f tape CH 



Prefix Machine(s) 


Operating System 


Language 




AC 


Acorn BBC Workstation 


Panos 


C 




AM 


Alpha Micro 68000 


AMOSL 


Alpha Asm 


68K 


APL 


Apollo 


Aegis 


Pascal 




APO 


Apollo 


Aegis 


Pascal 




BBC 


Acorn BBC Micro 


0S1 , 2 , 3 , Panos 


(various) 




CIE 


CIES 680/XX 


REGULUS 


C 




CN8 


(various) 


Concurrent CP/M- 8 6 


ASM86 




EXP 


TI Explorer 




Common Lisp 


FL 


Motorola 6809 


FLEX-09 or SK*D0S 


C or 6809 


Asm 


HL6 


Honeywell L6/10 


MS-DOS 


MASM 




HP 2 


HP-264x 


? 


8080 Asm 




HP 8 


HP-86, HP-87 


HP BASIC 


HP BASIC 




HP 9 


HUCSD p-System 


HP Pascal 






186 


Intel 86/380 


iRMX-86 


PL/M 




IRMX 


Intel 86/380 


iRMX-86 


PL/M 




LM 


LMI or Symbolics 


Lisp Machines 


ZetaLisp 




LUX 


Luxor ABC-800 


ABCD0S 


BASIC- II 




M2 


Lilith Workstation 


Medos 


Modula-2 




MD2 


Intel Development System ISIS 


PL/M 




MDS 


Intel Development System ISIS 


PL/M 




OS 9 


Various 


0s9 


C 




PQK 


ICL/3 Rivers PERQ 


PERQ OS 


Pascal 




PRO 


DEC Professional-350 


P/OS 


Bliss 




QLK 


Sinclair QL 


QDOS 


C 




QL2 


Sinclair QL 


QDOS 


BCPL 
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Less popular micros & workstations f tape O') f con 1 tl -- 



Prefix Machine(s) 


Operating System 


Language 


QNX 


IBM PC, Rainbow, etc 


QNX 




C 


RML 


Research Machines 


R0S , ... 




C 


RMX 


Intel 286/10, etc 


RMX-86 




PL/M 


TRI 


various 


TRIPOS 




BCPL 


UCA 


Apple II 


UCSD p-System 




Pascal 


UCI 


IBM PC 


UCSD p-System 


IV. x 


Pascal 


UCJ 


Joyce Loebl Magiscan 


2 UCSD p-System 




Pascal 


UCM 


Pascal Microengine 


UCSD p-System 




Pascal 


UCT 


Terak 8510a 


UCSD p-Systera 


II. 0 


Pascal , Macro- 11 


UM 


U-Micro U-Man 1000 


CP/M-68K 




C & 68000 


VIC 


Sirius 1/Victor 9000 


MS-DOS 




C 
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Less popular minis & mainframes (tape D~) -- 



Prefix Machine(s) 


Operating System 


Language 


AOS 


Data General 


AOS, AOS /VS 


Fort an, Pascal 


B68 


Burroughs B6800 


? 


Algol 


B78 


Burroughs B7800 & A 


? 


Algol 


B79 


Burroughs B7900 


? 


Algol 


CDC 


CDC Cyber 170 


NOS 


Fortran-77 


CD3 


CDC Cyber 


NOS 


Fortran 5 


CR 


Cray-1, Cray-XMP 


CTSS 


Fortran-77 


*CUC 


( various ) 


Unix 


C 


CVK 


Comput ervis ion 


CGOS 


Fortran S 


CYB 


CDC Cyber 


NOS 2. 2 


Compass 


DGM 


Data General 


AOS/VS with MV/UX 


C 


DTS 


Honeywell 6000 


DTSS 


Virtual PL/I 


GEC 


GEC 4000 Series 


OS-4000 (RAL) 


SERC 


GM 


Gould/SEL-32 


MPX-32 


Fortran 77+ 


GUTS 


IBM 370 Series 


GUTS 


Assembler 


HI 


Harris 100 


VOS 


Fortran 


H8 


Harris 800 


VOS 


Pascal, Asm 


HC6 


Honeywell DPS 8, 66 


CP6 


PL/ 6 


HCP 


Honeywell DPS 8, 66 


CP6 


Pascal 


HD 6 


Honeywell DPS 6 


GCOS 6 


?(no source) 


HDP 


Honeywell DPS 8, 66 


GCOS 


B 


HG 


Honeywell DPS 8, 66 


GC0S3 or 8 


C 


HP3 


Hewlett-Packard 3000 


MPE 


SPL 


HPM 


Hewlett-Packard 1000 


RTE-6/VM & RTE-A 


F-77 & Asm 
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Less popular minis & mainframes (tape D^l fcont'dl 



Prefix Machine(s) 


Operating System 


Language 


IBM 


370 Series 


MUSIC 


Assembler 


K08 


DEC PDP-8 


OS8, RTS 8 


PAL- 8 


DEC 


PDP-8 


OS-278 


PAL-8 


MOD 


MODCOMP Classic 


MAX IV 


Fortran/ASM 


MTS 


IBM 370 Series 


MTS 


Asm, Pascal 


MT2 


IBM 370 Series 


MTS 


PLUS 


MU 


Honewyell 


MULTICS 


PL/ 1 


ND 


ND-10/100/500 


Simtran III Rev J 


ND Pascal J 




CDC Cyber 


NOS 2.4 


Compass 


PER 


Perkin-Elmer 3200 


OS/32 


Fortran 




Perkin-Elraer 3200 


OS/32 MT72 


Fortran 


PE 7 


Perkin-Elmer 7000 


IDRIS 


C 


PIC 


Microdata (McD-Dougl) 


REALITY (PICK) 


DATA/ BASIC 


PRI 


PRIME 


PRIMOS 


PL/P (PL/ I) 


RDOS 


Data General Nova 


RDOS 


Fortran 


RD2 


Data General Nova 


RDOS 


Basic 


RT 


PDP-11 


RT-11 


OMSI Pascal 


SP9 


Sperry 90/60 


VS9 


Assembler 


ST 


HP3000, Univac, etc 


Software Tools 


Ratfor 


TAN 


Tandem 


Nonstop 


TAL 


TI9 


TI-990 


DX10 


Pascal 


UN 


Sperry/Univac-1100 


EXEC 


Assembler 


VME 


ICL 2900 


VME 


S3 


VX 


VAX 


VMS 


Pascal and Fortran 



* UCL C-Kermit (Prefix CUC, Tape D): 

A trim version of Kermit from England, written in C, without all the fancy features 
of the above C-Kermit, but possibly somewhat more efficient. Runs on Berkeley and 
ATT Unix systems. 
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-Documentation sources. mail archives. etc. (“Tape 



BY 


Byte Mag Kermit Article, Jun-Jul 84 


English 


GER 


Kermit documentation in. . . 


German 


IBM 


IBM mainframe Kermit discussion panel 


English 


KP 


Kermit Protocol Manual 


English 


KU 


Kermit User Guide 


English 


MA 


Info-Kermit Electronic Mail Digests * 83-now 


English 


NEW 


Kermit Newsletters 


English 


POR 


Kermit documentation in. . . 


Portuguese 



* Manuals and other documentation (Tape E): 

Note: The protocol manual and user guide were 
recently moved to Tape E due to lack of space on the 
other tapes. 

There are two Kermit manuals: KUSER and KPROTO, a user's guide and a 
protocol manual, respectively. They are provided in three forms: 

.MSS Scribe (UNILOGIC Ltd text formatter) source. 

.DOC No special effects, suitable for reading at a terminal. 

.FOR Fortran carriage control for overprinting, etc. 

If you have Scribe and the appropriate Scribe device drivers, you can run the 
.MSS files through it to produce output suitable for printing on any device supported 
at your site, including the Xerox-9700, Imagen, Apple LaserWriter, or other 
multifont laser printers or photocomposers. Note that some parts of the user manual 
rely on underlining to clarify examples; the underlines are missing from the .DOC files, 
but will be produced if you run the .MSS files through Scribe for a device capable of 
underlining (line printer, daisy wheel, laser printer, etc). 

The user's guide is intended for users of Kermit (including those who want to install 
it), the protocol manual is for those who would like to write a new implementation 
(i.e. a Kermit program for a new machine or operating system). 
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IMPORTANT: The Users Guide is always out of date. New implementations 
of Kermit, and new versions of old ones, arrive in a steady stream. It's impossible to 
keep the manual totally current. The general description of Kermit operation remains 
valid, but detailed descriptions of the various versions are better obtained from the 
accompanying help (.HLP), beware (.BWR), documentation (.DOC), memo (.MEM), 
or manual (.MAN) files. Look to these files for information missing from the user 
manual. 

For a detailed presentation of Kermit, from tutorials on computers, files, and 
data communications, to a thorough description of the protocol itself, plus a com- 
mand reference, command summary, troubleshooting guide, glossary, index, and many 
tables and illustrations, see the book "Kermit, A File Transfer Protocol," by Frank da 
Cruz, Digital Press (1986), ISBN 0-932376- 88-6, available from Kermit Distribution at 
Columbia, or directly from Digital Press, 12A Esquire Road, Billerica, MA 01862, order 
number EY-6705E-DP, S25.00. 

ASCII. MSS is the ASCII/EBCDIC character table, which is included as an ap- 
pendix in both manuals. 

KUSER.HYP is a hyphenation dictionary for building the 
manuals with Scribe. 

BYTE. MSS is the manuscript of the KERMIT article that 
was published in BYTE Magazine in June and July, 

1984. 

BYTE.DOC is suitable for reading at the terminal, 

BYTE. MSS may be run through Scribe to produce 
output for various printing devices, BYTE. BIB is 
the bibliography. 

MAIL.* is the archive of the CCNET/BITNET/ARPANET KERMIT 
discussion group. 

MAIL.TXT is the current, active mail file, found on Tape A. 
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MAIL.yyx (e.g. MAIL.83A) files contain older messages, 
and these are kept on Tape C. 

MAIL.HLP describes the format of the mail files. 

*** IMPORTANT *** 

Before doing anything with any particular version, look for an associated file with 
the suffix ".IILP" (help) or ".BWR" (beware). These files will often tell you special 
things you should know before starting to put together a working program from the 
distribution. 



* MS-DOS Kermit Implementations (Prefix MS, Tape A): 

See the file MSAAAA.HLP for an explanation of xMS-DOS Kermit file naming 
conventions. The following .BOO files are provided for current MS-DOS imple- 

mentions. BOO files are downloaded and decoded into .EXE files using 

MSBOOT.FOR on the mainframe and MSBPCB.BAS on the MS-DOS system, or 
downloaded directly to the PC and translated to .EXE files using MSBPCT.BAS or 
MSBPCT.EXE (compiled from MSBPCT.C), or MSBPCT.PAS (Turbo Pascal). Some 
of the MSVNBOO files correspond to version 2.30 of MS-DOS Kermit, others to 2.29, 
and still others perhaps even to earlier version. It depends on which was the latest ver- 
sion successfully tested on that machine. For fallback purposes, BOO files for old re- 
leases for some systems may be found in MSONBOO. Beta tests of new releases are 
in M ST*. BOO. 



MSV55X.BOO Sanyo MBC-550 with IBM compatible 



video board 



MSVAP3.BOO 

MSVAPC.BOO 

MSVAPR.BOO 

MSVDM2.BOO 



NEC APC3 
NEC APC 
ACT Apricot 

DECmate-IIJII with XPU (MS-DOS) 



option 
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MSVGEN.BOO 

MSVGRI.BOO 

MSVHP1.BOO 

MSVHPX.BOO 

MSVIBM.BOO 



Generic MS-DOS 
Grid Compass II 
Hewlett-Packard 150 
HP- 110 and HP Portable Plus 
IBM PC, Portable PC, XT, AT, PCjr**, 
and compatibles 

MSVMBC.BOO Sanyo MBC-550 

MSVRB1.BOO DEC Rainbow 100 Series 

MSVRB2.BOO A special fancy Rainbow version that 

does VT220 emulation 

MSVRMX.BOO Intel 300 series with iRMX-86 

Texas Instruments Professional PC 
Wang PC 
Heath/Zenith 100 
Victor 9000 (Sirius 1) 



MSVTIP.BOO 

MSVWNG.BOO 

MSVZIO.BOO 

MXVV90.BOO 



Source and other MS-DOS Kermit files: 



MSU*.ASM 
MSX*.ASM 
MS Y*. ASM 
MSZ*.ASM 



MSSDEF.H,MSS*.ASM Sources 

MSG*. ASM System dependent graphics terminal 

emulation 

System dependent keyboard support 
System dependent source modules 
Terminal emulation modules 
Continuation of terminal emulation 
-when MSY module too big 

MSKERM.DOC Kermit User Guide chapter for MS-DOS 
Kermit (long) 

MSKERM.HLP Brielf list of MS-Kermit commands 
MSKERM.BWR "Beware File" -- Known bugs & 
limitations. Read it! 

MS*.HLP, MS*.BWR Help and Beware files for specific 
systems. 
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The IBM version runs on the entire IBM PC and PS/2 families, clones and compat- 
ibles (e.g. Compaq, AT&T 6300, DEC VAXmate), and near-clones like the 
Heath/Zenith 100 with UCI EZPC board, Olivetti M24, Seequa Chameleon, and Data 
General/ 1. 

The generic version (MSVGEN) should run on any MS-DOS system, because 
it operates using only DOS calls. But this means it runs slowly (usually 1200 baud or 
less), and cannot do fancy screen management or terminal emulation. 

The Tandy, Honeywell, and some other MS-DOS versions listed above under their 
own prefixes are based on older versions of IBM PC Kermit; these have yet to be merged 
with the current MS/PC-DOS version. Volunteers? 

* WKERMIT (Tape A): 

An adaptation of an early version of C-Kermit to run on the IBM PC family and 
compatibles. It is the first PC implementation of Kermit with the sliding window pro- 
tocol extension. The .EXE file is formatted as a .BOO file (see above). It requires 
a modem, or a null modem cable that provides normal modem signals. The source code 
for WKERMIT should not be used as the basis for any development, as it is several 
releases behind C-Kermit. 

* WINKERM (Tape A): 

A version of Kermit specifically tailored for the multitasking Microsoft 
Windows environment. 

* CP/M-80 Kermit Implementations (Tape A): 

The following .HEX files for specific CP/M-80 implementations are in- 
cluded: 

CP4*.ASM The current, working source files for CP/M 
KERMIT. 
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CP4KER.DOC User documentation (chapter from the 
manual). 

CP4KER.HEX System-independent portion, to be combined 
with one of the following system-dependent 
"overlays": 



CP4380.HEX Research Machines RM380Z 
CP438M.HEX Research Machines RM380Z 
CP4S20.HEX Xerox 820 
CP4ACC.HEX Access-Matrix 
CP4ADV.HEX North Star Advantage 
CP4APC.HEX Apple II, Z80 Softcard, CPS serial card 
CP4APL.HEX Apple II, Z80 Softcard, 6551 ACIA in 
serial interface 

CP4APM.HEX Apple II, Z80 Softcard, Micromodem II in 
slot 2 

CP4BB2.HEX BigBoard II (terminal required) 

CP4BBC.HEX Acorn BBC Micro, Z80 second processor 
CP4BRA.HEX Intertec SuperBrain, aux port. 

CP4BRM.HEX Intertec SuperBrain, main port. 
CP4BRN.HEX Intertec SuperBrain. 

CP4CIF.HEX Cifer 1886 
CP4COM.HEX Comart Communicator 
CP4CP3.HEX "generic": CP/M 3.0 (CP/M Plus) systems 
(terminal req'd) 

CP4CPT.HEX CPT-85xx word processors with CompuPak 
CP/M 

CP4CRO.HEX Cromemco 

CP4DEL.HEX Digicomp Delphi 100 (terminal required) 
CP4DIS.HEX Action Computer Enterprises Discovery 
CP4DM2.HEX DECmate II with CP/M option 
CP4GEN.HEX "generic": CPM 2.2 systems with IOBYTE 
(terminal req'd) 
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CP4H89.HEX Heath/Zenith H89. 

CP4H0R.HEX North Star Horizon without SIO board 

CP4HP1.HEX Hewlett-Packard 125 

CP4KPR.HEX Kaypro-II (and 4; probably supports all 



Kaypro systems) 



CP4LOB.HEX 

CP4MDI.HEX 

CP4MIK.HEX 

CP4NST.HEX 



Lobo Max-80 

Morrow Decision I (terminal required) 
MikroMikko 

Northstar Horizon with Northstar CP/M and 



SI 0-4 board 



CP40SB.HEX Osborne 1 
CP40SI.HEX Ohio Scientific 

CP4PMM.HEX Personal Micro Computer MicroMate 
CP4PX8.HEX Epson PX8 Portable 
CP4R0B.HEX DEC VT180 
CP4TEL.HEX TELCON Zorba portable 
CP4TLB.HEX TRS-80 model II with Lifeboat 2.25C CP/M 
Display 

CP4T0R.HEX BBC Torch Series 

CP4TPT.HEX TRS-80 model II with Pickles + Trout CP/M 
Display 

CP4TTK.HEX Teletek with ADM-22 terminal 



CP4UDI.HEX Morrow Micro Decision I (terminal required) 
CP4VEC.HEX Vector Graphics. 

CP4Z00.HEX Z- 100 under CP/M-85 



The following are standalone hex files that can be directly loaded (not combined 
with CP4KER.HEX): 

CPMH8.HEX Heath H8 (based on version 3.5 of CP/M-80 • 

Kermit) 

CPMPRO.HEX Compupro Interfacer 3/4 (based on version 
3.9) 

CPMSYO.HEX Sanyo MBC 1 100 (version 3.9) 
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The Kermit User Guide contains instructions for installing or bootstrapping the 
various versions of CP/M Kermit. The bootstrapping program is also stored in the 
files CP4FET.*. A BASIC program, CP4HEX.BAS, can be used on the CP/M 
system to verify and edit a downloaded hex file prior to loading. 

* CP/M-86 Kermit Implementations (Tape A): 

The CP/M-86 Kermit file names all start with C86. Those whose fourth char- 
acter is X are system-dependent files for particular systems: 

C86XAP NEC APC 

CS6XFJ Fujitsu Micro I6s 

C86XFU Future FX20/FX30 

C86XRB DEC Rainbow, CP/M-86/80 V2 (C86XR2 is an 

alternate version) 

C86XTX Tektronix 4170 

C86XV9 Victor 9000/Sirius 1 

The .H86 files are hex files, convertible to runnable .CMD files by running them 
through GENCMD on the micro. There's also a Concurrent CP/M-86 version under 
the prefix CN8 (on Tape C). 

* Queen's University Turbo Pascal Kermit (Tape A) 

Runs on several systems. All source files concatenated together into a big source 
file, QKKER.PAS, with component file separated by lines like 

(* +FILE+ filename *) 

The runnable program image (.COM file) is encoded into straight hexadecimal 
(2 hex digits for one byte from the .COM file) for the following systems: 



QKMSTV.HEX 



IBM PC family, MS-DOS, with VT100 & 
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Tektronix 4010 emulation 

QKMSVT.HEX IBM PC family, MS-DOS, with VTiOO 
emulation 

QKCPK2.HEX Kaypro II, CP/M-80 

QKAPP2.HEX Apple II, DOS 

A simple Turbo Pascal program is provided to convert these hex files back into 
.COM files — QKHEXC.PAS. Key definition files are also provided; you need to 
have one on your current disk in order to run the program. 

* Other Files (All tapes): 

AAAREAD.ME is a file that describes some other files 
which can help you find your way among the 
hundreds of Kermit files. 

AAFILES.HLP is this file. 

AATAPE.HLP explains the format and layout of Kermit • 
tapes. 

AAXFLY.DOC is the Kermit "brochure" and order form. 

AAVNEW.HLP is a list of the current versions of Kermit 
in reverse chronological order, to help you see 
what has changed since the last time you looked. 

AAWAIT.HLP is a list of Kermit versions reportedly under 
development, for which we are still waiting. 

AAXCOM.HLP is a policy statement concerning commercial 
use of Kermit. 

AABLIND.IILP is a list of hints for use of Kermit, and 
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microcomputers in general, by the blind or people 
with other disabilities. 

KERM1T.FOR is a short receive-only version of Kermit 
written in Fortran, to be used for bootstrapping 
Kermit onto systems that don't have a real Kermit 
from a system that does. 



* Tools (Tape A): 

LASM and MLOAD are the public-domain CP/M-80 linking assembler and 
loader, that run on the CP/M system, and may be used to build Kermit-80. 

UUDECO.C is a version of UUDECODE that has been changed to supply any 
trailing blanks on lines in UUENCODEd files that may have had them stripped off 
by electronic mail (like on BITNET). 

XXU.C is a program for use on Unix systems that renames files with "foreign" 
names (e.g. uppercase, or including directory or path information, generation 
numbers, etc), to have normal Unix-style names. 

XXTAPE.* is a program to write ANSI and EBCDIC labeled tapes on a Unix 
system. Also needs XXATOE.C. 

APXA*.* is a program written in C that does what CROSS does, but only 
produces 6502 output (CROSS can produce many formats). This program can 
assemble Apple DOS Kermit (APPLEK.M65). (Actually, there might be 
minor differences in syntax, like whether or not a colon is required after a label...) 

* DEC- 10/20 Tools: 

The following tools are specific to DECsystem-10 and DECSYSTEM-20 com- 
puters, and will not appear on distribution tapes for other kinds of systems, and will 
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only appear at the end of DEC-10/20 tapes if there is sufficient room. The tools files 
are stored separately in KTt, < KERMIT-TOOLS> . 

The files MAC80.*, M80UNV, etc, are an 8080/8085/ZS0 cross assembler that runs 
on the DEC-10 or DEC-20; MAC80.DOC is a brief description. TORTUR.M80 is 
an 8080 instruction set "torture test" for MAC80, which illustrates its features. 

ZORTUR.M80 is a Z80 instruction set torture test. MAC80 is used to assemble 
CP/M KERMIT, and is mostly compatible with the standard CP/M 8080 assembler, 
D.R. ASM. 

HEXIFY.* is a program for converting a CP/M .COM file resident on the 
DEC- 10 or DEC-20 to a CP/M .HEX file. This is handy when binary file transfers 
are failing to work for some reason. The .HEX file can be LOADed on the CP/M 
system in the normal way to reconstruct the original .COM file. HEXCOM.* is the 
inverse of HEXIFY, and provides .HEX-to-.COM file conversion. 

The files CROSS.* are a general purpose cross assembler that runs only on the 
DEC- 10 and -20; CROSS.DOC is the manual. CROSS is used to assemble Apple DOS 
and Commodore-64 Kermits. 

WRITEL is a program to write ANSI labeled ASCII tapes on the DEC-20; it is 
written in Rutgers Pascal, and requires that you have the Rutgers Pascal runtime 
library on your system. 



* Finally... 

If you make any significant modifications to Kermit, fix any major bugs, or write 
any new implementations or documentation, please send them back to us onmagnetic 
tape (or IBM PC DOS format diskettes) so we can distribute them toother Kermit users: 



Kermit Distribution 
Columbia University 
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Center for Computing Activities 
612 West 115th Street 
New York, NY 10025 

We'll return your tapes back to you with the latest 
Kermit distribution (if you send full-size reels). 
Specify format and tape selection according the Kermit 
order form (copy in AAXFLY.DOC). 



* OTHER WAYS TO GET KERMIT * 

To get Kermit on magnetic tape from Columbia 
University, follow the directions in the file 
AAXFLY.DOC. There are also other ways to get Kermit: 

. Network Distribution: 

The file AANETW.HLP contains instructions for 
accessing the Kermit distribution over a variety of 
computer networks and dialup hosts. AANOKS.DOC tells in 
detail how to access the Kermit archive at Oklahoma 
State University. 

. Floppy Disk Distribution: 

A list of volunteer individuals and organizations distributing Kermit on 
floppy disks of various formats can be found in the file AADISK.HLP. Kermit 
diskettes may also be ordered in several formats from Columbia University (see 
AAXFLY.DOC). 

. Overseas sources for Kermit Distribution tapes: 

UK and Ireland (ANSI and VAX/VMS BACKUP tapes, selected diskettes): 
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Alan Phillips 
Communications Group 
Department of Computing 
Computer Building 
Lancaster University 
Lancaster LAI 4YW, ENGLAND 
Phone 0524-65201 x 4881 

France, Belgium, etc (European ANSI tape distribution tree) 

Jean Dutertre 

Institut Francais du Petrole 

BP 311 

92506 Rueil Malmaison Cedex, FRANCE 
Phone +33 1 749.02.14 



West Germany (ANSI tapes): 

Dr. Hans-Magnus Aus 

Institut fuer Virologie und Immunbiologie 

Universitaet Wuerzburg 

Versbacherstrasse 7 

D-8700 Wuerzburg 

WEST GERMANY 

Phone (931) 201-3954 

Australia: 

Rodney Van Cooten (or The Kermit Coordinator) 
University Computing Services 
University of Melbourne, 

Parkville, 

Victoria, 3052, 
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AUSTRALIA 

E-Mail: "munnari!murdu.oz!rvc"@SEISMO.CSS.GOV 
Japan 

Ken-ichiro Murakami 

NTT Basic Research Laboratories 

3-9-11 Midori-cho, Musashino-shi 

Tokyo, 180 

JAPAN 

Telephone : 0422-59-3589 

E-mail address : "nttlab!murakami''@ Shasta (from 

ARPA) or murakami@nttlab.ntt.junet (from JUNET, the 
Japanese domestic network.) 
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APPENDIX D. ACCESSING KERMIT FILES VIA COMPUTER 

NETWORKS 

This file is resident on the Columbia University Center for Computing and was accurate 
as of 20 Jan 88. It is up-dated yearly. 



This file describes how to get Kermit files over computer networks, including 
BITNET, CCNET (a DECnet network), the Internet (Arpanet and the networks 
connected to it), plus various dialup accesses including UUCP. You should also read 
AAFILES.HLP if you need more complete descriptions of the Kermit files them- 
selves. 



* BITNET from the Columbia University CUVMA System: 

BITNET is a network of computers, mostly at universities,. connected with leased 
phone lines, using IBM mainframe RSCS protocols (VAX VMS and Unix systems 
and other systems that can imitate these protocols are also on BITNET). BITNET 
covers North America, Europe (where it is called EARN), and has recently spread 
to the Far East. Information about joining BITNET may be obtained from 
EDUCOM Networking Activities, P.O. Box 364, Princeton, NJ (USA) 08540, Phone 
609-734-1878. 

KERMSRV at CUVMA is a file server for the BITNET user community which 
accepts commands via messages or spool files, and sends the requested KERMIT files 
over the network. Most spool file formats are accepted including those used by 
SENDFILE, NOTE, PUNCH, PRINT, CARD DUMP, or DISK DUMP commands. 

To learn how obtain Kermit files from the Columbia IBM mainframes via 
BITNET, type the following command to your BITNET host: 

VM/CMS: TELL KERMSRV AT CUVMA HELP (or SMSG RSCS 
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MSG CUVMA KERMSRV HELP) 

MVS/TSO/E: TELL KERMSRV AT CUVMA HELP (syntax may be 
site dependent) 

VMS JNET: SEN/REM CUVMA KERMSRV HELP 
UNIX UREP: netexec cuvma msg cuvma kermsrv help 

The Kermit files available from BITNET may be some days or weeks behind the 
announcements that appear in Info- Kermit (see below). 

Here is a brief summary of KERMSRV operation; see the HELP message for 
greater detail: 

The following file request commands are accepted: SEND, MAIL, PUNCH, 
PRINT, DISK, and CARD. These commands expect a file name or "DIR" or "?" as 
an operand. The DIR operand accepts an optional file name also. File names may 
contain * or % wildcard characters, but the filename portion may not consist of those 
characters only. 

Note that KERMSRV will always respond with some message; if you get a response 
please do not resubmit your request. If your request was received as a spool file, error 
messages are sent in a spool file, also. 

The NEWS command returns news about latest features and changes in 
KERMSRV. 



* BITNET from the University of Toledo VAX/VMS system UOFT02: 

The Kermit file server KERMSRV is not the same one as the one running at 
Columbia - this is a VAX, and CUVMA is an IBM mainframe. The collection is 
maintained by Brian Nelson, author of PDP-11 Kermit, mail to BRIAN@UOFT02 on 
BITNET. 

for instance, from VM/CMS: 
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CP SMS G RSCS MSG UOFT02 KERMSRV DIR 
CP SMSG RSCS MSG UOFT02 KERMSRV SEND Kll*.* 

(or TELL KERMSRV AT UOFT02 DIR, etc.) 

from VMS Jnet: S SEN/REM UOFT02 KERMSRV SEND Kll*.* 

Attempts to see if Kermsrv is 'logged in', e.g. SEN/COM UOFT02 CPQ U 
KERMSRV or SM RSCS MSG UOFT02 KERMSRV CPQ U KERMSRV will AL- 
WAYS fail. This is a VMS node running JNET and JNET treats server processes 
in a manner unlike VM does. 

For all pratical purposes, KERMSRV is always running. If a message is sent to it, 
and for some reason it's not there, JNET will tell you. 

Secondly, KERMSRV can ONLY respond to interactive messages, it can not 
process mail. 

Additional "satellite" BITNET KERMSRV sites may be established in the 
future to relieve congestion at the major US East Coast hubs. The need is particularly 
great on the West Coast and in Europe. Volunteers? There is also some possibility 
of converting from KERMSRV to the more general and powerful LISTSERV fa- 
cility. 

* Internet from the Columbia University CU20B System: 

"Internet" means the Arpanet and any network connected to it using TCP/IP pro- 
tocols, including parts of CSnet, many campus local networks, etc. Access to the 
Columbia Internet Kermit distribution is through FTP, the Internet File Transfer 
Program; consult the FTP manual for your own system in order to learn how to use 
your FTP program. 

To get Kermit files via the Internet, use FTP (not TELNET), connect to host 
CU20B (Internet Host number ffll28.59.32.128“), login as user ANONYMOUS, 
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password KERMIT, and use the GET or MULTIPLE GET commands to retrieve the 
desired files from the area KER:, e.g. "GET K E R : A A A REA D . M E" , "MULTIPLE 
GET KER:CK Network users may consult the file KER:AAVNEW.HLP from 
time to time to see what new versions of Kermit have been installed recently. Sites 
whose FTP programs do not support the DIRECTORY or MULTIPLE GET com- 
mands may GET the file AAFILx.DIR from the desired Kermit area (see below) to 
obtain an up-to-date directory listing. 

After logging in anonymously, you may also attempt to set your default path to 
the desired Kermit directory, KER:, K2:, K3:, K4:, or K5: (see below), using FTP's 
CWD or CD command. If you are prompted for a password, provide a null one; if a 
message advises you to send a password, ignore the message. Since our network 
software is always in a state of transition, this operation may or may not work. 
The following discussion assumes it does not work; if it does, you can follow the 
same instructions, but leave off the prefix KER:, K2:, K3:, etc, from any file specifica- 
tions. (But if an operation fails, then try again but with the prefix.) 

Internet access to CU20B is currently unrestricted, but if sufficiently large num- 
bers of anonymous FTP logins occur regularly during prime (eastern) time hours to 
interfere with our own user community, some restrictions on anonymous logins will 
have to be imposed. 

Those accessing CU20B via network should note the existence of several Kermit file 
areas: 

KER: - Popular microcomputer, PC, workstation Kermit 

implementations. 

K2: - Popular mainframe and minicomputer Kermit 

implementations. 

K3: - Less popular micro & PC Kermits (spillover 

from KER:). 

K4: - Less popular mini & mainframe Kermits 

(spillover from K2:). 

K5: - Mail archives, full-text user guide, protocol 
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manual, etc. 

KB: * True binary (executable) files for selected 

implementations. 

KE: - "Extra", old, redundant, or "limited-edition" 

Kermit implementations. 

KT: - Tools — cross assemblers and linkers, etc., 

mostly to run on DEC-20. 

KO: - Old releases superseded by new ones. 

KER: corresponds to Tape A, K2: corresponds to Tape B, 
to Tape C, K4: to Tape D, K5: to Tape E. 

These areas are "logical device names", which should be used rather than physical 
DEC-20 DEVICE: < DIRECTORY > names, which may change from time to time 
as our systems are rearranged. The logical name KER: includes all the others (K2:, 
KB:, etc) in its search path in the order listed above, so to obtain a single file you should 
prefix its name by KER:. 

When getting either single or multiple files, and your own system is a DEC-20, 
then it is also sufficient to prefix the file specification by KER:. 

When getting multiple files from CU20B's FTP server from non-DEC-20 systems, 
you should first change working directory (CWD or CD) to the area containing the 
files you want to get, e.g. KER: or K2:. If you don't, then each file will be sent back 
to you with its fully qualified name which in some cases may be longer than the 
longest permissible filename on your system, which in turn can cause files whose 
names differ only in the last few characters to overwrite each other as they arrive. 

Alphabetic case is insignificant in DEC-20 file names (lowercase is mapped to 
upper). The dot separating the file name and file type is significant; the name and type 
are separate fields. 

File groups may be specified in MULTIPLE GET commands using the following 
"wildcard" notation: 
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* matches any string of 0 or more characters in the 
current field 

% matches any single character in the current position 



For instance, KER:CK*.* matches all files whose names start with CK. 
KER:CK*.% matches all files whose names start with CK and whose types are 
exactly one character long (like KERtCKUCMD.C). The dot in DEC-20 
filenames separates the filename from the filetype. KER:* will NOT match all the files 
in KER: (as Unix users might expect), but rather, all the files in KER: that have null 
filetvpes. Use *.* to match all files. 

Each implementation of Kermit has a additional prefix imbedded in the name. 
All files relating to that implementation have names that start with that prefix. Since 
the dot is significant in DEC-20 file names, the way to refer to all the files in a 
specific implementation is "KER'.xx*.*", where xx is the prefix, e.g. KER'.MS*.* for all 
the MS-DOS Kermit files. 

A few cautionary words about DEC-20 logical names: the search path is followed 
only so long as files are not found that match the given file specification. This can 
cause some confusion; for instance, the command "DIRECTORY KER:" will only list 
the files in the primary (Tape A) Kermit directory, because when no file specification 
is given, "*.*" is assumed, and all files in the primary directory match "*.*", so 
subsequent directories are not searched. Similarly, "KER:C*.*" will not search sub- 
sequent directories if the primary directory contains any files that start with "C". Note 
that "KER:*. DOC" (whose intention might be to refer to all the Kermit doc- 
umentation files) would only find .DOC files in the primary Kermit directory. 

Care has been taken to ensure that files are arranged so that if they are referred 
to by prefix, they will be found in the KER: search path. For instance, the C-Kermit 
files, having the prefix "CK" will be found if referred to as "KER:CK*.*", even though 
they are really in K2:. However, this principle applies only to the principal directories, 
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KER:, K2:, K3:, K4:, and K5:. It does not apply to KB:, which is used to separate bi- 
nary files from "printable" files. Therefore, KER: MS*.* will find all of the printable 
MS-DOS Kermit files, but will not find the .EXE files, which are in KB:, and must 
be referred to separately as KB:MS*.*. 

Before you attempt to get binary files from the KB: or KT: directories with FTP, 
you should know something about the way the DEC-20 stores these files: 

. Native DEC- 10 or DEC-20 programs are stored in 36- 
bit binary format, and will be transferred correctly to 
other DEC-10 or -20 systems without doing anything 
special. They probably can't be transferred to other 
kinds of systems, except maybe 36- bit Honeywells or 
Sperrys. 

. "Foreign" 8-bit binary files are stored four 8-bit 
bytes left justified within the 36-bit word. You can 
get these files from another DEC- 10 or -20 without 
doing anything special, but to get them from some other 
kind of system, you have to give FTP the command "TYPE 
L 8", "type binary", and/or "TENEX" first. 

If you are originating your FTP requests from a DEC-20 or TENEX system, no 
special precautions are necessary regarding file types or name conversion. If you are 
coming from another kind of system, you will probably find that the files you obtain 
are stored with names contrary to your system's naming conventions. For instance, 
if you tell Unix FTP to "mget ker:ck*.*", you may find the files stored in your directory 
with names like 



PK: < KERMIT> CKAAAA.HLP.2 
when you really want stored with names like 

ckaaaa.hlp 



94 



A special program is available to Unix sites for doing the appropriate file name 
conversions, called xxu.c ("get kenxxu.c"). The recommended procedure for 
FTP’ing files to a Unix system is to make a new directory for them, cd to it, then get 
the files, including kenxxu.c, then build xxu.c (just type "cc -o xxu xxu.c"; the result 
should run under any version of Unix), then do "xxu *" to convert the names. See 
the xxu.c source comments for details. 



USING KERMIT WITH AN INTERNET TERMINAL ACCESS CONTROLLER 
(TAC). 

(Thanks to Edward Haines < haines@BBNCCI.ARPA> for these hints) 

There are some conditions that must be met to successfully use Kermit on a per- 
sonal computer through a TAC. 

Flow Control 

The buffer size for a terminal port on a TAC is typically about 64 bytes. (The size 
is a configuration parameter.) Since the default packet size in Kermit is usually 80-96 
bytes it is quite likely that buffer overflow will occur. 

Some possible solutions: 

1. Enable flow control in Kermit on the PC and on the 

TAC. Many PC versions of Kermit implement XON/XOFF flow 

control, including the MS-DOS version for the IBM PC. 

To enable flow control on the TAC issue the TAC commands 

@Flow Input Start 

@Flow Output Start 

These are usually abbreviated @f i s and @f o s. Note 
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that flow control is not compatible with binary mode 
(except see note below). . 

2. Make the packet size on the PC Kermit small enough 
to not overflow the TAC buffer, e.g. 60 bytes. The 
normal command is "set receive packet-length 60", which 
you give to the Kermit that is about to receive files. 

3. Increase the buffer size in the TAC. This is not 
usually practical and won't be considered further. 



TAC Intercept Character. 

The default TAC intercept character is the AT-sign. The AT- sign is also required 
by the Kermit Protocol, so unless you take one of the measures listed below, Kermit 
packets won't get through the TAC. 

Solutions 

1. Have the PC Kermit automatically double AT-signs on 
output. This is probably the best solution in general. 

This feature is available on some PC implementations of 
Kermit. It is not yet available on the MS-DOS version. 
fflEd. - It's available in CP/M-80 Kermit 4.0x.“ 

2. Change the TAC Intercept character with the command 
@Intercept < decimal ASCII value > 

For instance, "@I 6" sets the intercept character to Ctrl-F. 

3. Put the TAC into Binary mode. This has the side 
effect of disabling the Intercept character. It also 
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will allow you to transfer binary files without special 
encoding. The TAC can be put into Binary mode with the 
commands 

@Binary Input Start (@b i s) 

@ Binary Output Start (@b o s) 

Some host systems allow you to engage the binary mode 
from the host. DEC-20 Kermit has a command for this. 

There are several problems with binary mode: 

Some host systems don't support it. 

You lose the ability to control the TAC from the PC. 

You lose the ability to do XON/XOFF flow control. 

Binary Files 

It is sometimes desireable to be able to transmit an 8-bit binary file between a host 
and a PC. The TAC (which implements the DDN Telnet Protocol) normally provides 
just a 7-bit ASCII path. 

Solutions 

1. Enable binary mode (if possible) as described 
above. 

2. Enable 8th bit prefixing (if available) in both 
Kermits. (This is usually done by enabling parity via 
Kermit's SET PARITY command.) 

Notes 



1. You will probably get the best 
throughput for ASCII files by keeping the 
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packet size as large as possible and using 
flow control. 

2. There is not much advantage in 
increasing the baud rate between the PC and 
the TAC beyond 1200 baud because of the 
relatively long turnaround time for the 
acknowledgement packet. 

3. You may have problems when going through 
satellite hops or multiple gateways due to the 
occasional very 7 long delays. This may result 

in Kermit giving up. The problem can be 
circumvented to by increasing the timeout 
interval; many Kermits have commands to allow 
this: SET SEND/RECEIVE TIMEOUT. 

4. Only the first letter of a TAC command 
is required. 

5. It is possible to set binary mode in 
only one direction. For example you can set 
Inbound binary and retain input flow control 
(XON/XOFF flow is in the opposite direction). 
You probably don't need outbound (input to the 
PC) flow control when using the Kermit 
protocol. 



* CCnet: 

CCnet is a DECnet network of cooperating universities. Kermit files may be 
accessed using NFT to CU20B::KER:xxx.yyy, where xxx.yyy is the name of the file 
or file group you want to get. Some sites (regarded as "secure") may specify 
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/USER:ANONYMOUS, but most sites will have to supply a valid CU20B user ID and 
password. If your system is on CCnet and you cannot get anonymous NFT access to 
CU20B, you'll have to ask your system manager to get the files for you. Read the 
Internet section above about device, directory, and wildcard conventions. 



* United Kingdom (Information from Alan Phillips, Lancaster University): 

Though there is a central registry of UK site names known as NRS, it is not auto- 
matic and many people have no access to it, so include the actual DTE addresses if you 
can. Details for mail: 

JANET network : SYSKERMIT @ UK.AC. LANCS. VAX 1 

(actual address is 
0000 10404000. FTP.M AIL) 

PSS network : SYSKERMIT@23425240010l. 

0000 10404000. FTP. MAIL or to 
the JANET address via the 
Rutherford gateway 

BITNET : SYSKERMIT%LANCS.VAX1 @ UK.AC 

ARPA : SYS KERMIT% LANCS. VAX 1 @ CS.UCL. 

AC. UK 

We do not support file transfer to BITNET/ARPA - users have to log in as a ter- 
minal and use KERMIT. Over PSS and JANET we support ftp using Blue Book 
protocol: For details pull file 00INFO.TXT from user KERMIT, quoting password 

KERMIT. FTP address is 

JANET : 0000 10404000. FTP 

PSS : 234252400101. 000010404000. FTP" 
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Or people can just mail me and I'll send details. Afraid we have no equivalent of the 
BITNET KERMSRV server or Arpa anonymous ftp over here. Dial-up ports are 
available; I'll send details to anyone wanting them. 

While we're very' happy for anyone to ftp from us or log in to us from anywhere, 
and we'll put anyone on the mailing list, we can't handle letters and phone calls from 
outside the UK and Eire. Nor can we send files to people who can't ftp them. 



* Mail: 

There is a network mailing list for Kermit information; it is available to users 
of BITNET and the Internet and most networks that are connected to them, 
inclusing CSnet, Usenet, Mailnet, CCnet, and others. To get on the mailing list, send 
mail: 



- From - - To - 

BITNET KERMIT@CUVMA 

CCNET Info-Kermit-Request@CU20B 

Arpa Internet Info-Kermit- 

Request@CU20B.COLUMBIA.EDU 
CSNET Info-Kermit-Request%CU20B. COLUMBIA. 

EDU@CSNET-RELAY 

Mailnet I nfo-Kermit-Request%CU20B. COLUMBIA. 

EDU@MIT-MULTICS 
Usenet ...!uunet!columbia!cu20b!info- 

kermit-request 

DEC Easynet DECWRL::"Info-Kermit-Request@CU20B. 

COLUMBIA.EDU" 

UK JANET SYSKERMIT@UK.AC.LANCS.VAX1 

If your system won't let you use long names or names with dashes in mail ad- 
dresses, then just substitute "KERMIT" for "Info-Kermit-Request". 
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Also, as of December 1988, the Kermit mailing list is available via BITNET 
LISTSERV. This is a facility that lets you subscribe and unsubscribe yourself. To 
subscribe via LISTSERV, send an electronic mail message to LISTSERV@CUVMA. 
The body of the message should contain the line: 

SUBSCRIBE I-KERMIT your personal name 

For instance 

SUBSCRIBE I-KERMIT Fred C. Dobbs 
To remove yourself from the list, send the following message: 

UNSUBSCRIBE I-KERMIT 

To learn more about LISTSERV, send it a message "HELP" or "INFO ?". 



* Dialup: 

Several publicly accessible dialup Kermit collections are available in the US: 

1. The University of Toledo allows limited dialup access to its UOFT02 VAX/VMS 
system: 



(419) 537-4411 
Service class VX785A 
User: KERMIT 
Password: KERMIT 

Source and hex files are in KER:, binaries are in KERBIN: 
2. Oklahoma State University: 
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UUCP and Kermit access to the complete Kermit distribution is available from the 
Department of Computing and Information Sciences, Oklahoma State University, 
Stillwater, Oklahoma. The procedures are somewhat complicated, and are described 
in a separate file, AANOKS.DOC. 
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APPENDIX E. KERMIT USER'S GUIDE 



This is a step-by-step guide for using KERMIT to access the NPS mainframe from 
a Heath/Zenith 100 or 89 microcomputer. The procedures were developed by the long 
proven scientific trial and error method and some very old notes from a 1984 file on the 
mainframe titled "Z100h89 fullscrn B". If you happen upon improvements and/or cor- 
rections to this guide, please provide them and any other comments to the computer 
department so they can be added. This and the other KERMIT text files were written 
by R. G. Bishop in April 1987 at the request of the NPS Computer Center. 

A. KERMIT IN GENERAL 

There are many help files and documents available to help you become familiar with 
KERMIT commands and attributes. These help files and KERMIT User Guides can 
be accessed through the BITN'ET, Defense Data Network (DDN) and the mainframe. 
Rather than attempt to duplicate them here, you should access them yourself if you are 
in need of further information. This instruction sheet will provide all the information 
you need to access the mainframe and from there you can learn more. 

1. Versions of KERMIT 

There are more than 200 versions of KERMIT circulating around for over 50 
specific machines and more than 5 for MS-DOS in general. This instruction set is writ- 
ten for KERMIT version 2.27 which is available from the computer department with 
several special changes set up to communicate with the mainframe using a Z- 100/89. 

2. Required Files 

You will need both MSZ100.EXE and MEKERMIT.INI on your disk to use 
these procedures. The original disk for this instruction sheet includes KERMIT.DOC 
and READ. ME. 

B. BRIEF OVERVIEW OF PROCEDURES 

1. Dial into the Mainframe accessing SIM3278. 

2. Choose the VT100-in-the-VT52-mode terminal emulator package. 

3. Set up your Z- 100/89 in the alternate keypad mode. 

4. Log on exactly as you would from a terminal at school. 

5. Decide whether to transfer files or do screen editing. 

6. Use substitute keys to imitate the PF keys. 
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1. The Details 

a. Loading KERMIT for MS-DOS 

NOTE: For this instruction sheet "<CR>" means carrage return key, 
<esc> means escape key and <ctrl> means control key. Under most 
circumstsnces you will use the < Ctrl > key simultaneously with another key. 

Put the disk containing KERMIT in the active drive and enter: 



MSZ100 <CR> This loads KERMIT and the system 

will respond with with: 

Heath-Zenith Z-100 Kermit-MS V2.27 
Type ? for help 

KERMIT-MS> 

When the prompt appears enter: 



DO IBM < CR > This will set up the communications 

protocall to the correct values and 
return the prompt, KERMIT-MS > . 



b. Set Up Modem 



Now turn your modem on and enter: 



Connect or C < CR > This begins the connect sequence. 
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Next "dial" the mainframe. For an auto-dial modem enter: 



ATD6462709 < CR > This will call-up the computer for 

1200 or 300 baud operation. 



NOTE: If you do not have an auto-dial modem follow your modem's 
instructions for call or dial-up. 

The system will respond with: 

CONNECT 1200 

VM/370 ONLINE- -PRESS BREAK KEY TO BEGIN SESSION 
! Enter <CR> 



The system will respond with: 

Enter one of the following commands: 



LOGON userid (Example: LOGON VMUSER1) 

DIAL userid (Example: DIAL VMUSER2) 

MSG userid message (Example: MSG VMUSER2 GOOD MORNING) 
LOGOFF 



This is the mainframe dot prompt. 



DO NOT GO FURTRER UELLL XM. REM THE, next secttor 

\ 

DO NOT GO FURTHER UMIL YOU SEAR IRK NEXT SECTIM 
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c. What do you want to do this session ? 

At this point you must make a decision about what you want to do. If you 
wish to transfer files, see TRANSFERRING FILES, if you wish to do full screen editing 
(same as being on a terminal at school) continue with the section, SCREEN WORK. 

( 1 ) Screen work. You have dialed up the Mainframe and must now get 
to the period prompt. DON'T log on with your user id yet. Instead enter the following: 



DIAL SIM3278 < CR > This will connect you to the 

mainframe's communications 
protocall software. 

The system will respond with: 

DIALED TO SIM3278 091 S I M 3 2 7 8 (C) Simware Inc. 1984 VERSION 3.4 

Please Enter Your Terminal ID; T for menu, 'V for LOGOFF 



When asked what type of terminal you are, enter: 

9 < CR > You may look at the menu if you 

want by entering ? You enter 9 to 
choose the DEC VT100 in the VT52 
mode, and press RETURN. 

The screen will clear and the large NPS logo will appear like the one on the 3270 con- 
sole's at school. 



Now you must enter a sequence which will turn your keypad on and place your Z-100 
keypad in the Alternate character mode. Enter: 

< esc > x7 < CR > Note the small (lower case) x. 

Place the H-89 in the shifted 
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keypad mode by pressing < ESC > x6. 
(Note the lower case x.) 



= = > The Z-100 has separate arrow keys on the keypad. Use 
these to move the cursor around. 

= = > On the H-89, the shifted keypad mode allows the arrow 
keys to work as is. To access the rest of the functions, 
you must press the shift key with the keypad key. 



The system will respond with: 

Enter one of the following commands: 

LOGON userid (Example: LOGON VMUSERi) 

DIAL userid (Example: DIAL VMUSER2) 

MSG userid message (Example: MSG VMUSER2 GOOD MORNING) 
LOGOFF 



This is the mainframe dot prompt. 

Logon as you would normally do at a terminal by entering: 

logon XXXXP <CR> Where XXXX is your user Number. 

Your password WILL show up on the 
srceen, but no matter. This should 
also execute your exec files as 
normal after logon. If not press 
return again. 

The system will respond with the LOGON message and leave you with the system 

prompt "dot". 
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There is an attachment to this instruction which shows the key equivalents for the Z-100. 
In all cases you must enter the keys (in sequence if more than one) and end with a car- 
riage return <CR>. 

(2) Transferring files. To transfer files you must "set the mainframe up" 
to send or receive a file first . Then "drop" down to your KERMIT and do the trans- 
ferring. To drop down, you must enter control, right bracket, < ctrl> “, simultaneously, 
and then enter the appropriate send or receive on your KERMIT. 



Logon as you would normally do at a terminal by entering: 

logon XXXXP < CR > Where XXXX is your user Number. 

Your password WILL show up on the 
srceen, but no matter. This should 
also execute your exec files as 
normal after logon. If not press 
return again. 

The system will respond with the LOGON message and leave you with the system 
prompt "dot". 



Now link to the mainframe's KERMIT by entering: 

Linkto KERMIT < CR> The system will respond with: 

Linked to user kermit disk 191... 
and will give you the KERMIT-CMS> 
prompt. There is no help file 
avaliable, but ? displays the 
KERMIT options avaliable. This may 
again execute your exec files. 
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If you have forgotton which file you wanted to send or just want to look, you can see 
your filelist (directory) by entering the following sequence: 

QUIT or Q < CR > Quits kermit and returns to cms at 

which time you can enter: 

listfile < CR > Which will display your directory. 

to get back to kermit enter: 

KERMIT < CR > The system will display KERMIT-CMS. 

To send a file from the main frame to home computer enter: 
send filename file type filemode < CR > 

< Ctrl > -] <CR> Drops to your KERMIT-MS> prompt. 

recei filename. extension <CR> ? 



At this time you will see a file transfer status menu. This will give you a menu which 
shows how the transfer is w’orking.When the transfer is complete it will tell you (along 
with some other ? facts about that file ? 



d. Logging off 

You logoff at the end of your session as normal and then enter: 
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< Ctrl > -C] < CR > 



The control, < Ctrl > , and right 
bracket “ must be done at the same 
time (simultameously) and then the 
C and < CR> . 

Now you are at the KERMIT-MS> prompt. Enter: 

QUIT or Q < CR > This will bring you back to the 

operating system. 



2. Tips for 300 baud users 

Since 300 baud can be very slow, try to minimize those actions which call for a 
complete screen update. Some examples: 

1. In XEDIT, do most of your corrections on the whole page (using the arrow keys) 
before you move Up or Down. Then move a whole page if possible. 

2. In the Input mode in XEDIT, use the NEWLINE function (ESC < cr> ) to move 
the cursor down to column one of the next line instead of pressing <cr> alone. 
RETURN < cr> causes the whole screen to be updated as the lines you've entered 
so far, are moved up above the action. Once you have entered seven or so lines, 
then press <cr> to accept the lines and update the screen. 

3. Z- 100/IBM 3270 keyboard equivalence 

Use Figure 11 to imitate the various function keys normally found on the 3270 
terminals connected to the IBM at NPS. 
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HOME/ SCHOOL KEY EQUIVALENCES 



Here are some key equivalences: 



VT-52 (term 9) IBM 3270 CODES 



H89 (KP=Keypad) 


Z-100 


KEYS 


SENT 


REMARKS 


— 


— > 


ARROW 


KEYS < 






<- - 




<-- 


<- - 


<ESC> D 




shift 6 




shift 6 


shift 6 


<ESC> A 




V 




V 


V 


<ESC> B 




- -> 




--> 


- -> 


<ESC> C 







=> FUNCTION 


KEYS < 












BLUE<cr> 


F6<cr> 


PF1 


<ESC> 


P 








RED<cr> 


F7<cr> 


PF2 


<ESC> 


Q 








WHITE<cr> ' 


F8<cr> 


PF3 


<ESC> 


R 








Fl<cr> 


Fl<cr> 


PF4 


<ESC> 


S 








shft KP 7<cr> 


KP 7<cr> 


PF5 


<ESC> 


7 


w 






shft KP 8<cr> 


KP 8<cr> 


PF6 


<ESC> 


? 


X 






shft KP 9<cr> 


KP 9<cr> 


PF7 


<ESC> 


? 


y 






ESC ? m <cr> 


KP -<cr> 


PF8 


<ESC> 


? 


m 






shft KP 4<cr> 


KP 4<cr> 


PF9 


<ESC> 


? 


t 






shft KP 5<cr> 


KP 5<cr> 


PF10 


<ESC> 


? 


u 






shft KP 6<cr> 


KP 6<cr> 


PF11 


<ESC> 


? 


V 






? 


? 


PF12 












shft KP l<cr> 


KP l<cr> 


PA1 


<ESC> 


? 


q 


Goes 


to CP 


shft KP 2<cr> 


KP 2<cr> 


PA2 


<ESC> 


? 


r 


? 




shft KP 3<cr> 


KP 3<cr> 


#G0T0(SIM) 


<ESC> 


? 


s 


1 


1 „ 


ESC<cr> 


ESC<cr> 


Newline 


<ESC> 






3270 


<-- key 


shft ENTER<cr> 


ENTER<cr> 


Alt Clear 


<ESC> 


? 


M 


also 


PA2 


CTRL a 


CTRL a 


Insert char 


<CTRL 


a> 






CTRL b 


CTRL b 


Delete char 


<CTRL 


b> 


once 


for each 



char to delete 



Figure 11. Z100/IBM 3270 Key Equivalence: NOTE: Some of the function keys 

have not been located, If you find errors or more definitions, let us 
know. 



4. The Quick'N'Dirty Version 

After doing this several times you will get to the point when you do not need 
all this information to operate in the KERMIT environment. Figure 12 fits neatly on 
a three by five card which can be tucked into the jacket of your KERMIT disk. 



Ill 



1 



" MAINFRAME' N KERMIT " 


MSZ100 <CR> 




DO IBM <CR> 




modem on Connect <CR> 


ATD6462709 


Tn TTTT F C 


• wnpTf ....... 


JL U i A xlJULb 


OwIviLiliiN W L/Xvja. 


LOGON XXXXP <CR> 


DIAL SIM3278 <CR> 


LINKTO KERMIT <CR> 


<esc>x7 <CR> 


Q <CR>, LISTFILE <CR> 


LOGON XXXXP <CR> 


KERMIT <CR> 




set mainframe firstl 


LOGOFF <CR> 


LOGOFF <CR> 


<ctrl>-C <CR>, QUIT 



Figure 12. KERJV1IT Quick Reference (3X5 card) (for NPS only) 
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APPENDIX F. TEKTRONIX TERMINAL EMULATOR 



The following programs were developed on the Z-100 using Z-BASIC under 
MS-DOS version 2. The programs used to generate the pictures in Appendix I were 
compiled by the Z-BASIC compiler. 

A. TEKTRONIX GRAPHICS TERMINAL EMULATION PROGRAM 



1 

2 

3 

4 

5 

6 

7 

8 

9 

10 
11 
12 
13 
20 
21 
22 
23 

30 

31 

32 

33 

34 

40 

41 

42 

43 

44 

50 

51 

52 

53 

54 

55 
60 

61 

62 

63 

64 

65 
70 
80 



' TECKTRONIX 4006 / 4010 GRAPHICS TERMINAL EMULATOR 
' FOR THE Z-100 UNDER MS-DOS MODIFIED FOR THE DDN 

I 

' ORIGINALLY SUGGESTED BY GLEN ROBERTS APRIL 28, 1984 
' UNDER Z-DOS TO MAKE THE Z-100 COMPUTER EMULATE A 
' TEKTRONIX PROTOCOL GRAPHICS TERMINAL 
' THIS VERSION WILL RUN UNDER MS-DOS 2 AND HIGHER 
' MODIFIED BY R. SABO AND R. BISHOP JAN 1988 

t 

DEFINT A-Z.-DIM P!(224):DEF SEG = &HE000 

I 

' CHARACTER CONSTANTS 

t 

CTRLC=3: FF=12: X0N=17: X0FF=19: ESC=27: GS=29: US=31: SPACE=32 

t 

' INITIALIZE VARIABLES 

I 

FALSE=0: TRUE=NOT FALSE: GRMODE=FALSE: HAVLOY=FALSE: A=0 

I 

' THE FOLLOWING COMMUNICATION PROTOCOL CONSTANTS MAY BE 
' MODIFIED AS NEEDED FOR THE APPLICATION YOU ARE UNDER 

I 

BAUD$= U 1200": PARITY$="N": BITS$="8 M 

' HOME THE CURSOR AND CLEAR THE SCREEN 
' TURN KEY ASSIGNMENTS OFF 

t 

SCREEN 0,0: KEY OFF: CLS 

t 

' INITIALIZE THE ARRAY TO INDEX THE BYTES 
' FOR BIT IMAGE PRINTING (NOT USED IN THIS VERSION) 



R=0: FOR J=0 TO 392 STEP 16: FOR 1=0 TO 8: P! (R)=( I+J)*128: 
R=R+1: NEXT I: NEXT J 

I 

' ASSIGN KEY INTERRUPTS TO THE 
' APPROPRIATE SUBROUTINES 

' THIS AREA IS WHERE FURTHER WORK CAN TAKE PLACE 

t 

KEY ( 1 ) ON: ON KEY(l) GOSUB 530 
KEY(2) ON: ON KEY( 2) GOSUB 560 
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90 

100 

110 

120 

130 

140 

150 

151 

152 

153 
160 
170 
180 
190 
200 
210 
211 
212 

213 

214 
218 
220 
230 

240 

241 

242 

243 

244 

245 
256 

250 

251 

252 

253 

254 

255 

256 
260 
261 
262 

263 

264 

265 

270 

271 

272 

273 

274 
280 
290 

292 

293 

294 

295 
300 
310 



KEY( 3) ON: ON KEY( 3) GOSUB 590 
KEY(4) ON: ON KEY(4) GOSUB 620 
KEY(5) ON: ON KEY(5) GOSUB 740 
KEY( 6) ON: ON KEY(6) GOSUB 470 
KEY( 7) ON: ON KEY( 7) GOSUB 760 
KEY( 8) ON: ON KEY(8) GOSUB 780 
KEY( 9) ON: ON KEY(9) GOSUB 800 

T 

' PRINT 25th LINE AND TITLE HEADING ON SCREEN 

t 

GOSUB 620 

PRINT "TEKTRONIX 4006 / 4010 GRAPHICS TERMINAL EMULATOR" 
PRINT 

PRINT "BAUD : ";: SCREEN ,1: PRINT BAUD$; : SCREEN ,0 
PRINT " PARITY : ";: SCREEN ,1: PRINT PARITY$; : SCREEN ,0 

PRINT " BITS : SCREEN , 1: PRINT BITS? ;: SCREEN ,0 

' OPEN SERIAL COMM CHANNEL AS FILE #1 
' OPEN SCREEN OUTPUT AS FILE #2 



OPEN "COMl: "+BAUD?+" , "+PARITY?+" , "+BITS? AS //I 

OPEN "SCRN: " FOR OUTPUT AS #2 

PAUSE=FALSE 

I 

' THIS IS THE MAIN EXECUTION LOOP 
' FIRST CHECK FOR CHARACTERS IN THE COMM BUFFER 
' IF NONE THEN JUMP TO SEE IF SYSTEM IS WAITING 
' FOR AN X-ON ALSO CHECK COMM BUFFER TO SEE IF FULL 

t 

IF LOC( 1)=0 THEN 430 
• 

' HANDLE HANDSHAKING IF COMM BUFFER IS ALMOST FULL THEN 
' SEND AN XOFF TO THE REMOTE SYSTEM TO STOP DATA 
' TRANSMISSION AND SET PAUSE TO TRUE TO INDICATE THAT 
' THE REMOTE SYSTEM IS WAITING FOR AN X-ON 

t 

IF ( LOC( 1)>60) AND NOT PAUSE THEN PAUSE=TRUE: PRINT #1 ,CHR?(XOFF); 

t 

’ SAVE THE LAST RECIEVED CHARACTER, THE READ A NEW CHARACTER FROM 
* THE COMM BUFFER 
' (STRIP THE 8TH BIT IF ANY) 

t 

LASTA=A: A=ASC( INPUT? (1,#1)) AND 127 

i 

' IF THE CHAR IS A CONTROL CHAR OR IF WE ARE 
’ NOT IN THE GRAPHICS MODE THEN JUMP 

i 

IF A<SPACE THEN 390 

IF NOT GRMODE GOTO 420 

' HANDLE THE GRAPHICS CHAR 

' PUT HIGH TWO BITS INTO MODE VARIABLE 

' THEN PUT LOW FIVE BITS INTO THE BITS VARIABLE 

f 

MODE=A 32: BITS=A AND 31 
ON MODE GOTO 320,340,380 
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311 

312 

313 

314 

315 

316 

317 

318 
320 

330 

331 

332 

333 

334 

335 

336 

337 

338 
340 
350 
360 

370 

371 

372 

373 

374 

375 

376 

380 

381 

382 

383 

384 

385 

386 

387 

390 

391 

392 

393 

394 

400 

401 

402 

403 

404 

407 

408 

409 

410 

411 

412 

413 

414 

415 



; FOR THE CASE WHERE MODE =01 (HIGH X OR HIGH Y) 

' IF WE ALREADY HAVE A LOW Y THEN THIS 
' MUST BE A HIGH X, ELSE IT MUST BE A HIGH Y. 

' SHIFT IT FIVE BITS SO THAT THE LOW VALUE 
' MAY BE ADDED LATER. 

I 

IF HAVLOY THEN HIX=BITS*32 ELSE HIY=BITS*32 
GOTO 430 

t 

' MODE = 10 (LOW X) 

t 

' THE HIGH AND LOW DATA IS COMPLETE, START DRAWING THE 
' VECTOR ON THE SCREEN. THIS IS DONE USING THE Z-BASIC 
’ "DRAW” STATEMENT. SCALING IS 5/8 X AND 7/24 Y 
' IF THE VECTOR IS INVISIBLE ADD "B" TO BLANK IT. 

I 

Y=15*(780-(L0Y+HIY)) 52: X=5*(BITS+HIX) 8 
L$=”M"+MID$( STR$( X) , 2)+" , "+MID$( STR$( Y) , 2) 

IF BLANK THEN L$="B"+L$ 

DRAW L$: BLANK = FALSE: HAVLOY=FALSE: GOTO 430 
' FOR THE CASE WHERE MODE = 11 (LOW Y) 

I 

' SAVE LOW Y VALUE AND REMMEMBER THAT WE HAVE 
' RECEIVED A LOW Y 

I 

LOY=BITS: HAVLOY=TRUE: GOTO 430 

I 

' HANDLE COTROL CHARACTERS HERE 

' IF A GROUP SEPARATOR (GS) THEN ENTER THE 

' GRAPHICS MODE AND REMMEMBER THAT THE NEXT VECTOR 

' WILL BE INVISIBLE (YOU ALWAYS START WITH AN INVISABLE 

' VECTOR SO YOU CAN POSITION TO THE CORRECT STARTING PLACE) 
» 

IF A=GS THEN GRMODE=TRUE: BLANK=TRUE: CLS: GOTO 430 

i 

' IF A UNIT SEPERATOR (US) THEN 
' EXIT THE GRAPHICS MODE 

i 

IF A=US THEN GRMODE=FALSE: LOCATE 25,1: GOTO 430 



' IF FORM FEED (FF) AND THE LAST WAS (ESC), THEN CLEAR SCREEN 
' AND THE 25TH LINE, THEN EXIT GRAPHICS MODE 

IF A=FF AND LASTA=ESC THEN CLS: LOCATE 25,1: 

PRINT SPACE$(80); : GRMODE=FALSE: GOTO 430 

' THE CHAR IS EITHER A NORMAL CONTROL CHAR 
' OR WE ARE NOT IN GRAPHICS MODE 
' JUST SEND IT TO THE SCREEN 
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420 

421 

422 

423 

424 

430 

431 

432 

433 

434 

435 
440 
450 

460 

461 

462 

463 

464 
470 
480 
490 
500 
510 
520 

522 

523 

524 

530 

531 

532 

535 

536 
540 
550 

554 

555 

556 

557 

558 
560 
570 
580 
590 
600 
610 
611 
612 

613 

614 

615 
620 
630 
640 
650 
660 
670 



PRINT #2,CHR$(A); 

' IF X-OFF HAS BEEN SENT SEE IF BUFFER IS ALMOST EMPTY 
' IF IT IS, SEND AN X-ON 

I 

IF (LOC( 1)<10) AND PAUSE THEN PAUSE=FALSE: PRINT #1 ,CHR$(XON); 

' NOW POLL THE KEYBOARD. IF A KEY HAS BEEN HIT 
' THEN TRANSMIT THAT CHARACTER TO THE REMOTE SYSTEM 
' AND GO BACK TO THE TOP OF THE LOOP 

I 

A$=INKEY$ 

IF A$<>"" THEN PRINT #1,A$; 

GOTO 250 

t 

' SUB TO PRINT SCREEN USING BIT IMAGE GRAPHICS ON C. ITOH PROWRITER 
' OTEHR SIMILAR PRINTERS. 

f 

BEEP 

t 



RETURN 

I 

' ROUTINE TO NAME AND SAVE SCREEN PICTURES 

I 

LOCATE 1,1: INPUT"PICTURE NAME: ",SCNM$ 

I 

BSAVE SCNM$, 0,50256! 

GOSUB 620 

BEEP 

RETURN 

I 

' THE SPACES HERE CAN BE USED TO PROGRAM THE "FUTURE" 

' THINGS REMOVED FOR OUT PROOF OF CONCEPT VERSION 
' WHEN CALLED THEY WILL JUST BEEP FOR NOW 

I 

BEEP 

BEEP 

RETURN 

BEEP 

BEEP 

RETURN 

SUB -ROUTINE TO CLEAR SCREEN AND PRINT A REMINDER PROMPT 
ON THE 25TH LINE. THE PROMPT SHOWS THE FUNCTION KEYS 
AND THEIR ASSIGNED STSTUS 



CLS: LOCATE 25,1 

PRINT " 1";: SCREEN ,1: PRINT "SAVE 
PRINT " 2";: SCREEN ,1: PRINT "FUTURE 
PRINT " 3”;: SCREEN ,1: PRINT "FUTURE 
PRINT " 4";: SCREEN ,1: PRINT "CLS 
PRINT " 5"; -.SCREEN ,1: PRINT "QUIT 



SCREEN ,0 
SCREEN ,0 
SCREEN ,0 
SCREEN ,0 
SCREEN ,0 
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680 


PRINT 


If 


6"; 


SCREEN 


,1: PRINT 


"FUTURE 


690 


PRINT 


If 


7"; 


SCREEN 


,1: PRINT 


" C 


700 


PRINT 


If 


8"; 


SCREEN 


,1: PRINT 


"XOFF 


710 


PRINT 


ft 


9"; 


SCREEN 


, 1: PRINT 


"XON 



: SCREEN , 0 
: SCREEN ,0 
: SCREEN ,0 
: SCREEN ,0 



1,1 



720 LOCATE 

730 RETURN 

731 ' 

732 ' CLOSE ROUTINE 

733 ' 

740 CLOSE: KEY OFF: CLS 

750 STOP 

751 

752 

753 

754 

755 



I 

' ROUTINES NEEDED TO SEND CONTROL CHARS NORMALLY 
' TRAPPED IN ZBASIC INTEREPRETED VERSIONS. MAY NOT 
’ BE NEEDED IN THE COMPILED VERSION 

f 



760 PRINT #1 ,CHR$(CTRLC); 
770 RETURN 

780 PRINT #l,CHR$(XOFF); 
790 RETURN 

800 PRINT #l,CHR$(XON); 
810 RETURN 



B. PLAYBACK PROGRAM LISTING 

While this is not very elegant it does serve its purpose. Further work on this pro- 
gram could do much to improve its functions. 



1 

2 

3 

4 

5 

6 



' THIS IS THE LO -CO-GRAF "PLAY BACK" PROGRAM 
' IT PROMPTS FOR THE NAME OF THE PICTURE TO 
' GET FROM A FILE AND THEN PAINTS IT ON THE SCREEN 
' AT THAT POINT, YOU CAN PRINT IT TO PAPER WITH THE 
' SCREEN DUMP PROGRAM 



20 CLS 

30 DEF SEG=&HE000 

31 ' 

33 ' LINES 40 THRU 70 GET THE NAME OF THE FILE DATA 

34 ' TO BE DISPLAYED, PLAY BACK THE PICTURE AND 

35 ' RINGS A BELL TO TELL YOU IT IS COMPLETE. 

36 ' 

40 INPUT "NAME OF PICTURE FILE TO LOAD FILENAME? 

50 CLS 

60 BLOAD FILENAME?, 0 

70 BEEP 

71 LOCATE 25,1: PRINT "ENTER ANY KEY TO QUIT OR" 

72 LOCATE 25,31: PRINT " PRESS SHIFT F-12 TO PRINT" 

90 A?=INKEY$: IF A$="" THEN 90 

100 STOP 
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APPENDIX G. SCREEN DUMP ROUTINE 



This documentation file is available on the distribution disk for the screen dump 
routine titled: 



SCDMP.COM - Version 3.4 - 15-Oct-85 
SCREEN DUMP UTILITY FOR H/Z-100 
(for U. S. Government use only) 



A. INTRODUCTION 

SCDMP is a utility that allows reproduction of a complete video screen on a 
dot matrix printer, including both text and graphics, without having to exit the 
current program. The SCDMP program may be loaded manually (by entering 
SCDMP <cr>) or automatically, via 'autoexec.bat', into memory at the beginning 
of a session where it remains resident until needed. To print a desired stationary 
screen, simply press <SHIFT-F12>, which generates an interrupt-5 and activates 
the screen dump. 

The program allows a choice of which color bank of video RAM is dumped (if 
the user has all banks of color RAM in hisZlOO). The number of VRAM banks 
installed in your computer is determined by SCDMP upon initial load. For the 
color version, entering a <B> for blue, <R> for red, <G> for green, or <A> 
for all banks immediately after the <SHIFT-F12> will select the VRAM bank to be 
printed. If no character is entered, <A>11 banks is the default. If only one bank 
of color RAM is installed, only the green bank can be dumped. 

The program also allows multiple density printing for some printers. Entering 
an <H> immediately after the <SHIFT-F12> or color selection would cause the 
printer to use a higher density mode for printing. The default density is normal 
or standard density. The program also allows a choice of printing the twenty-fifth 
line, if displayed. Entering a <D> immediately after the <SHIFT-F12> or 
color or density selection will cause SCDMP to dump the 25th line if it is dis- 
played. 

The program also allows the default values for the switch settings to be 
changed at any time after the program is loaded. Entering a < C > after any of the 
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above settings will cause a change in the default values only. They will be reset 
as requested and a beep will sound to confirm the reset. The screen will not be 
dumped. 

Approximately three seconds is allowed after initiation of SCDMP before the 
default values are assumed. The default values can also be changed at the time of 
initial load of screen dump, by entering the appropriate changes via the command line, 
such as 

SCDMP xyz < cr> 

where x = < B > lue, < R > ed, < G > reen, or < A > 11 banks default 
y = < N > ormal or < H > igh density default 
z = < D > ump 25th line, if displayed 

This will allow SCDMP to be setup with the proper defaults for your application. 
Activation would not require the switches after the <SHIFT-F12>. This 
makes calling SCDMP from within another program more versatile. 

In the event that it is necessary to stop the printing of a screen, entering 
<ESC> during printing of the screen will abort the dump (a 'Q' can also be used if 
called from within another program). 

SCDMP can be activated from within many popular programs such as Multiplan, 
ZBASIC, Graftalk, ZDS Business Graphics, Z-Chart, Doodler, CHART, and others. 
SCDMP will not work with Lotus 123 or Watchword as these programs bypass the 
MSDOS 'get character' call. SCDMP conforms to the operational 'standard' created 
by Zenith's PSC.ASM, except that both graphics and text are reproduced. 

B. REQUIREMENTS 

This program requires the ZDOS/MSDOS operating system (Version 1.25 or 
higher) on a H/Z-100 computer. The printers currently supported for U. S. Gov- 
ernment use are the Epson MX/RX/FX Series with Graftrax, the Okidata Microline 
83A, and Zenith/MPI 99/150 Series. 

C. DISTRIBUTION FILES 

The following files are included on the distribution disks of SCDMP. Documenta- 
tion for operation and modification of the programs is also included. 
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SCDMP .DOC Screen Dump information 

SCDMPEPS.COM Version for Epson MX Series 

SCDMPOK2.COM Version for Okidata Microline Series 

CDMPMPI .COM Version for Zenith/M PI 99/150 Series 

SCDMP .BAT Batch file for auto load of SCDMP.COM 
(rename the appropriate program to 
SCDMP.COM) 



D. INSTALLING THE PROGRAM 

Choose the version of the screen dump required by the specific printer ap- 
plication. Rename the version to SCDMP.COM as follows: 

REN SCDMPxxx.COM = SCDMP.COM 

Load the screen dump program into resident memory as follows: 

SCDMP <cr> or SCDMP xyz<cr> 

A sign-on message will display the version number and the printer application 
with instructions for dumping the screen. Screen dump instructions will be similar 
to the following: 

To dump screen, type: < SHIFT-F12> fflW“fflX“fflY“fflZ“ 

ffiW = < G> reen or < B> lue or < R> ed or < A> 11 banks" 

fflX = < N > ormal or < H > igh density" 

fRY = < D > ump 25tn line" 

fflZ = < C > hange default settings" 
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defaults: VRAM bank = A print density = N 



To abort dump during printing, type: < ESC> 

Typing of < SHIFT-F12> -W— X--Y--Z- will suspend execution of the current 
program, dump the screen to the printer, and return to the current program with no 
change. 



NOTE: Versions of SCDMP are available for 
other printers. Contact Mr. Les Bordelon at 
(714) 793-8853 for additional information. 

Program Author: 

Leslie L. Bordelon 
1453 Fernwood Drive 
Redlands, CA 92374 
714-793-8853 



Additional Credits to: 

Digital Information Systems (Original Graphics Routines) 
Zenith Data Systems (Interrupt-5 Handling from PSC.COM) 
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APPENDIX H. ACCESSING THE BRIEFING AID SYSTEM 



This file is on the DDN viewer system for accessing the Briefing Aid System. 
It explains how to configure the information file which must be placed in your DDN 
directory. The file is titled: 

< LEVEL2> USING-TAC-TERMINALS.DOC. 3 

Using a Graphics Terminal on the TAC 
Revised 27-Sep-83 

Before attempting to use a Graphics Terminal on a TAC, verify that port to 
be used is set in "Wild Mode" and "Quiet Mode". These settings must be authorized 
by the site liaison and executed by the Network Operations Center. Only if "Wild 
Mode" is enabled will the Graphics System be able to connect to the TAC; if not 
enabled, the Graphics System will simply minute during Initialization and then return 
an error (subcode = 64009). 

"Quiet Mode" suppresses all messages on the TAC port. This means no "TCP 
Trying...", "Open", or "Closed" messages should appear when attempting to use the 
Graphics Terminal as a regular terminal. 

Once you have determined that the port is correctly tailored, issue the fol- 
lowing commands to the TAC from your Graphics Terminal: 

@ RESET < return > 

(Theage similar to:) 

@PROTOCOL TCP < return > 

(This command should no longer be required) 

@ECHO HALFDUPLEX 

(Instructs the TAC not to echo characters) 
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Use another terminal to login and run your program using the string 
"DEVICE = (T,RAND-TAC-xxx)" in the INIT command, "xxx" should be the TCP 
port number, in octal, of the graphics terminal on the TAC. TCP port numbers may 
be calculated from the terminal port number in the herald after the RESET command 
(in the above case, the terminnumber is 3). 



Terminal Port Number 
1 
2 

3 

4 

5 

6 



TCP Port Number (Octal) 
427 
1027 
1427 
2027 
2427 
3027 



p 256 * p + 23 

(expressed in octal) 

For example, to run your program on a Tektronix connected to terminal port 4 on 
CCA-TAC use the initialization string: 

BACKEND = (TEKTRONIX), DEVICE = (T,CCA-TAC-2027) 



When you're done using the Graphics Terminal, you may have reset Echoing on 
the TAC porCHO REMOTE 
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APPENDIX I. SAMPLE MAPS GENERATED BY LO-CO-GRAF AND 

THE BRIEFING AID SYSTEM 



The following cartographic products were displayed by the LO-CO-GRAF terminal 
emulation system using the Briefing Aid System for map generation. The maps were 
transferred from USC-ISI via DDN to a Z-100 microcomputer and then printed on an 
Epson-equivalent dot matrix printer using a screen dump routine. Examples of maps 
and charts printed under these options are listed in Table 3. 



Table 3. GUIDE TO LO-CO-GRAF MAPS 



Map Title 


Page 


Airroutes.GPX 


37 


North-West Europe 


38 


Atlantic Ocean and Caribbean Sea 


125 


Mediterranean Sea 


126 


Tyrrhenian Sea 


127 


North Sea 


128 


English Channel with political boundaries 


129 


Straits of Hormuz 


130 


Ethiopian Conflict 


131 
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Figure 13. Atlantic Ocean/Caribbean Sea (solid landfill) 
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Figure 14. Mediterranean Sea (solid landfill) 
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Figure 15.. Tyrrhenian Sea (solid landfill) 
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Figure 16 . North Sea (solid landfill) 
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Figure 18. Straits of Hormuz (Russian version) 
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Figure 19. Ethiopian Conflict (tactical map) 
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APPENDIX J. SAMPLE MAPS GENERATED BY DISSPLA 



The generated maps for the major systems described in this thesis follow. The dif- 
ferences in line thickness is a function of the printer being used and does not reflect on 
the cartographic resolution. These maps were generated by DISSPLA version 10.2 
World Coast Utilities Option and printed by an IBM 3800 laser printer. Examples of 
maps and charts printed under these options are listed in Table 4. 



Table 4. GUIDE TO DISSPLA GENERATED MAPS 



Map Title 


Page 


Washington, DC 


18 


North-West Europe 


39 


World Mercator Projection 


133 


Cape Canaveral/ Kennedy Space Center - 


134 


Carribean Operating Area 


135 


Mediterranean Operating Area 


136 


Japan and the Kurile Islands 


137 


Northern Flank of NATO 


138 


North and South America 


139 
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133 




134 




Figure 22. Caribbean Sea 
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MEDITERRANEAN SEA 







Figure 23. Mediterranean Sea 

o 
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Figure 24. Japan and the Kurile Islands 
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S5 




Figure 25. Northern Flank of NATO 
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Figure 26. North and South America 



139 



BIBLIOGRAPHY 



Cruz, Frank and Fischer, Herm, KERMIT Version 2: 26 Documentation, Van Nuys, CA: 
Litton Data Systems, 1984. 

Defense Communications Agency's DDN New User Guide, Menlo Park, CA: DDN In- 
formation Center, SRI International, December 1985. 

Field Manual FM 21-33, Terrain Analysis, Washington, DC: Department of the Army, 
1978. 

Frazier, Larry, Technical Note VM-07, Special Printing on the IBM 2800, Monterey, CA: 
Naval Postgraduate School, July 1986. 

Galfney, Steven James and Daly, James Earl, Tactical Use of Digitized Maps, Master's 
Thesis-Naval Postgraduate School, Monterey, CA, September 1987. 

Guth, Peter L., TERRANAL: Microcomputer Terrain Mapping Package, Las Vegas, NV: 
University of Nevada, 1986. 

Guth, Peter L., Ressler, Eugene K., and Bagastow, Todd S., Micro DEM: Microcomputer 
Program for Manipulating Large Digital Terrain Models, West Point, NY: U. S. Military 
Academy, 1985. 

Huchingson, R. Dale, New Horizons for Human Factors in Design, New York, NY: 
McGraw-Hill Book Company, 1981. 

Kantowitz, Barry H. and Sorkin, Robert D., Human Factors: Understanding People- 
System Relationships, New York, NY: John Wiley and Sons, Inc., 1983. 

Kelly, A1 and Pohl, Ira, An Introduction to Programming in C, Menlo Park, CA: The 
Benjamin/Cummings Publishing Company, Inc., 1984. 



140 



Liu, Yu-Cheng and Gibson, Glenn A., Microcomputer Systems: The 8086/8088 Family- 
Architecture , Programming, and Design, Second Edition, Englewood Cliffs, NJ: Prentice- 
Hall Inc., 1986. 

Marateck, Samuel L., BASIC, Third Edition, Orlando, FL: Academic Press, Inc., 1986. 

Microsoft Z-Basic (Z-DOS), Benton Harbor, MI: Heath Company, 1982. 

NyhofF, Larry and Leestma, Sanford, FORTRAN 77 for Engineers and Scientists, New 
York, NY: Macmillan Publishing Company, 1985. 

Stivison, Douglas S., Turbo Pascal Library, Berkeley, CA: SYBEX Inc., 1986. 

Triebel, Walter A. and Singh, Avtar, The 8086 Microprocessor Architecture, Software, 
and Interfacing Techniques, Englewood Cliffs, NJ: Prentice-IIall Inc., 1985. 

User's Guide to the TOPS-20, Marina Del Rev, CA: University of Southern California 
Information Sciences Institute (USC-ISI), April 1984. 

VS FORTRAN Compiler and Library Reference Summary, Sixth Edition, San Jose, CA: 
International Business Machine Corporation, May 1985. 

Work Station Handbook For DISSPLA/ Dynamics and ISSCO-GKS Users Current with 
D1SSPLA 1 0.0, San Diego, CA: Integrated Software Systems Corporation, 1985. 

Z-100 Technical Manual, Vol. 1 and 2, Saint Joseph, MI: Zenith Data Systems Corpo- 
ration, 1983. 



141 



LIST OF REFERENCES 



1. Field Circular FC 100-15, Corps Operations, Fort Leavenworth, KS: U.S. Army 
Command and General StafF College, March 1984. 

2. Patton, George S., Jr., GEN, L'SA, War as I Knew It, Boston, MA: Houghton 
Mifflin Company, 1947. 

3. Clarkson, Albert, Toward Effective Strategic Analysis: New Application of Informa- 
tion Technology, Boulder, Co: Westview Press, 1981. 

4. Mullen, Cassius J., "C3I Decision Making" Defense Science and Electronics, Vol. 6 
No. 12, December 1987. 

5. Backlund, William V., MAJ, USA, et al., Command and Control Microcomputer 
User's Group Software Catalog, Fort Leavenworth, KS: C2 MUG, Vol. VI, No. 2, 
December 1987. 

6. Univesity of Southern California, Information Services Institute (USC-ISI), Brief- 
ing Aid System, DARPA, 1987. 

7. Koi, D. B., Generalized Geographic Mapping System for Computer Graphics, 
NOAA-TM-NMFS-153, April 1985. 

8. "CBD Watch: Defense Mapping Agency", Federal Computer Week, Boston, MA: 
GSN Inc., 8 February 1988. 

9. Reznick, Greg, "Understanding PC Graphics", The Government Micro User's Guide, 
Chantilly, VA: Government Technology Services, Inc., Winter 1987. 

10. Sanders, Mark S. and McCormick, Ernest J., Human Factors in Engineering and 
Design, Sixth Edition, New York, NY: Mc-Graw Hill Book Company, 1987. 



142 



11. Collins, Patricia, Technical Note VM-12, Using Disspla at NPS, Monterey, CA: 
Naval Postgraduate School, November 19S6. 

12. DISSPLA Pocket Guide Current with Version 10.0, San Diego, CA: Integrated 

Software Systems Corporation, 1986. 

13. Adney, William M., "IBM Compatibility; Real or Imagined?", Remark, Benton 
Harbor, MI: Heath Company, July 1984. 

14. Pang, Eric L., "Taking Graphic Drawing Across a Number of Microcomputers and 
a Minicomputer", Remark, Benton Harbor, MI: Heath Company, September 1986. 

15. Roberts, Glenn F., "Tektronix Terminal Emulation for Your Z-100", Sextant, 
Washington, DC: Sextant Publishing Company, September-October 1985. 

16. Bordelon, Leslie L., "Screen Dump Utility for H/Z-100, SCDMP.COM-Version 3.4 
Documentation File, 15 October 1985. 



143 



INITIAL DISTRIBUTION LIST 



No. Copies 



1. Defense Technical Information Center 2 

Cameron Station 

Alexandria, VA 22304-6145 

2. Library, Code 0142 2 

Naval Postgraduate School 

Monterey, CA 93943-5002 

3. Naval Postgraduate School 1 

Code 55St 

Monterey, CA 93943-5000 

4. Naval Postgraduate School 1 

Code 56Fk 

Monterey, CA 93943-5000 

5. Naval Postgraduate School 1 

Code 39 

Monterey, CA 93943-5000 

6. Naval Postgraduate School 7 

Code 74 

Monterey, CA 93943-5000 

7. Air Force Institute of Technology 2 

AFIT/CISK 

Wright-Patterson AFB, OH 45433-6583 

8. Air University Library 2 

AU/LD 

Maxwell AFB, AL 36112-5001 

9. Commanding Officer (Attn: Editor, Chips) 1 

Naw Regional Data Automation Center 

Norfolk, VA 23511-6497 

10. Air Force Communications Command 5 

AFCC/AII 

Attn: Capt. Bishop 
Scott AFB, 1L 62225-6001 

11. Surface Warfare Officer School 3 

Department Head Class 104 

Attn: LT Sabo 
Newport, RI 02841 



144 






311 - ? 




Thesis 

S 1445 Sabo 

c.l LO-CO-GRAF : generating 

maps to support command & 
control/crisis management 
using small computers. 



P’ op 



